Jump to content

Kalvan

Members
  • Content Count

    59
  • Joined

  • Last visited

  • Days Won

    1

Kalvan last won the day on September 10

Kalvan had the most liked content!

Community Reputation

35 Excellent

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Of the keyboards I've personally used, my favorite layout was the original Steel Series APEX, and my favorite in terms keyboard feel was the APEX M800, essentially a larger keyed mechanical switch version of the previous, but with certain changes to the layout to bring down costs that I didn't agree with. I also came to like (aspects of) the Sharp X68000 keyboard layout, as well. My ideal layout would be a mix of the best parts of the Steel Series APEX (Especially the macro keys and double-wide space bar) and Sharp X68000 keyboards (especially the Arrow Key and upper function key keybank), with mechanical witches. If money was not an issue, I would call either Steel Series (because they made the original) or Unicomp (because I live relatively close to them) and commission that layout (with new labels for the Windows and space bar rank Print Screen keys) for the my Hibana Main Sequence project.
  2. Oh, please do tell. The more (useful) criticism I get on this project, even from folks not actually helping me with HDL code, the better. For the current record, my plan at this time for the use of the graphics hardware is that the SILVER object generators would be used for things like tile patterns, horizons, HUDs, generic simple mobile objects with simple motion patterns, and oncoming ground scenery like the trees and bushes in Space Harrier or billboards in driving/racing games, and PENNY sprite engines for things like player characters, or anything needing complex movement patterns, as well as things like fonts in text modes.* Sort of like the difference between the NEO GEO's "Pattern Sprites" and Nintendo Game Boy Advance/DS' Afine sprites. *Text sprites are part of the specification. Might as well make use of them.
  3. Obviously, it will need an OS with an easily usable windowing GUI, a sufficiently powerful command prompt console, and a built-in language easy enough to use that still exposes the graphics and sound hardware to the programmer, something along the lines of a compilable Action, but with more support for sound. Still, I didn't conceive of this project to be all things to all people, just as I'm sure Mr. Murray didn't conceive of the Commander X16 to be that way either. I intended this particular computer to have been of the hardware generation immediately after the Amiga OCS,(or for that matter, the Commander X16), to have been released in time to compete with the IBM PS/2, VGA/SoundBlaster era PC Clones, Apple Macintosh II/III, Sharp X68000, 1st and 2nd Generation Acorn Archimedes, and Fujitsu FM Towns, and to have provided a chipset capable of competing with the first and second generations of Sega's Scalar Arcade hardware (like Out Run, Super Hang On, Space Harrier, Afterburner, and Power Drift) or Namco's Thunder Ceptor and Taito's Top Speed or System Z (Aqua Jack and Chase HQ). Do I expect this venture to be a commercial success? Well, that would require me to define the word "success" for this context. I can only hope a number of people end up buying it to create a create a stable software ecosystem, and use it to produce memorable ports and original programs. Everything else is just details.
  4. Here's a bump, and an update adding the support chip post and a poll.
  5. My original plan for the main CPU and other support chips was to use a MIPS Level 1/2 for the main CPU (specifically a Microchip Technology PIC32 microcontroller) clocked to 35.8-57.2 MHz, with a WDC W62C265S for the Sound CPU, a Freescale or Renaisis version of the Motorola 68901 for controller and PS/2 mouse interface. a second source version of the Intel 8048/51 for PS/2 Keyboard interface, and base the expansion bus on an inverted version of either the IBM PS/2 Micro Channel Architecture bus, or else the MIT NuBus architecture, used by Apple, Atari, Acorn, and NeXT. However, while perusing Zilog's current catalog of ICs, I discovered that I could substitute Zilog chips for almost everything but the expansion bus and keyboard interface, and even add a separate video CPU to handle the graphics chips and video RAM independently, though not without potential pitfalls. Let me explain through some bullet lists: MIPS: Pros: Fully 32-bit architecture. Can address up to 4GB total RAM Hardware Integer Multiply and Divide Supported by all major forks of the BSD Project Cons: 32-bit data bus makes for, ahem, interesting bit priority interface puzzles Every major chip comes from a different manufacturer, making interface/driver programming an, uh, interesting experience. Zilog Pros: The Zilog eZ80 is only nominally an 8-bit chip, due to its "official" data bus being 8 bits wide. It has a 24 bit data bus, 24 bit mathematical instruction arguments, its registers are 32 bits wide to handle reusable spillover multiplication precision, and the 32 pins of GPIO mean a true effective data bus of 40 bits (with caveats). All of Zilog's chips use the same assembly language complex, albeit with a certain mild dialect divergence between families. This makes OS, high level language, and driver/feature stack writing much easier, except for the keyboard interface, but, who would bit-bang a purely input device like an 80's style keyboard? The eZ80's port layout is such that that a separate Video CPU a-la the Fujitsu FM-8/7/77 series is trivially easy to implement, assuming you route the motherboard properly, of course. This means that graphics interrupts need no longer be quite as taxing on main CPU time. The Zilog catalog includes several DSP models, perfect for adding to the graphics chipset* Cons: A mere 24-bit address bus (16 MB) for the eZ80 and 20 bit address bus (1 MB) for the Z180 I would plan to use for the Sound CPU is going to put a premium on memory map architecture, especially for the latter, as if I'm forced into Plan B, I will have to do a port/register connection to the SAM2595 to access the 512K MIDI instrument ROM rather than a DMA access, as the Seta X1-010 needs at least 512K to stretch its legs fully, especially in PCM mode. Is not part of any BSD Project fork, meaning that I will need to use something like SymbOS, MP/M, or a Frankensteined-together MSX-DOS-alike hack of DOSBox or Free-DOS. Note: *Internal documents for both SIERRA/RAINBOW and OMNI included the addition of a Texas Instruments TMS32000 series DSP. Unfortunately, finding a reliable supply of even second source/knockoff versions from the Mid-Late Eighties is an absolute crapshoot.
  6. For the sound system, I am planning on employing a Sound CPU with a grand total of 1MB of sound RAM, driving four specific sound elements: 1: a POKEY variant, specifically a QuadPOKEY, specifically, a POKEYMax 3.x. 2: AMY, unless creating an FPGA Core is too much trouble, in which case Plan B is to use the Dream SAM2695, which may force me to use a microcontroller with an extra DMA to handle its internal RAM buffer and instrument ROM. It's a subtractive MIDI synthesizer developed by reverse engineering the Roland MT-32's sound generator, so it's just as theoretically "mathy" as AMY, just in the opposite direction. Yes, 64 channels is blatant overkill, but Dream discontinued the 32 and 16 channel versions a while back. 3: A mid-late eighties Yamaha FM sound chip and (if necessary) matching DAC, or some second-source version from Casio, Alumer, or Phillips. I'm leaning towards the YM2414, whose tone I fell in love with on Youtube. It is an eight channel, four operator chip with eight possible wave forms. If I cannot find enough new old stock, I'd be willing to settle for a WM2151 or WM3812, the latter best known as the sound chip used in the original Roland Ad-Lib and Creative SoundBlaster sound cards. 4: Some wavetable and/or PCM sound chip. I'm leaning toward the Seta X1-010, because of its flexibility and the way it's already been integrated into the MISTer FPGA project, but I'm also looking at the Ensoniq ESS55 series (used in things like the Apple IIgs, the Advanced Gravis WaveMaster sound card, and several Ensoniq keyboards), the original SegaPCM, or one of the Ricoh RF5C series. AMY is an additive synthesizer using either 64 or 128 occilators (depending on application/conficuration) and a 16K control ROM. This is all the text I can find from the Atari History Museum. The rest of the files were .zip files of things like music samples and a digitized tape out of a preliminary (and presumably still buggy) version in a format no longer supported by industry standards. The real question is: Does AMY absolutely demand using an FPAA? If not, how many FPGA gates would be needed for a digital version, and how many LUTs would that translate to with the FPGA in the DE-10 Nano? And naturally, if I don't like the answer, I can always go with Plan B. AMY_1_spec_confidential_binder_ver_2.pdf AMY_chip2_notes.pdf AMY_development_notes.pdf AMY_formulas.pdf AMY_general_description.pdf AMY_tech_manual.pdf
  7. Obviously, the graphics chips are the stars of the show. I plan to use HEATHER as the basis of my primary display adaptor. I chose HEATHER from OMNI over GOLD from RAINBOW for four main reasons: 1: GOLD lacks an actual color generation scheme (that's on another chip, whose notes are unavailable). 2: GOLD can only address 1 MB of Video RAM, while HEATHER can address 16 MB. 3: HEATHER includes all the bus signals of GOLD, in addition to signals all its own. 4: VIVIAN includes DRAM Refresh Hardware. That said, I am toying with going with a different color generation scheme: The complex color generation method that only generates 2304 possible colors makes little sense when something like the Commander X16 can manage 4096. I am towing with either a 16-bit or 24-bit color method, for reasons involving my indecision involving the CPU and Support Chips. The 160bit scheme would involve two 15-bit schemes, selectable between the two with the top bit. The first scheme would be five bits each of RGB, while the second scheme would be three bits each of magenta, yellow, cyan, negative luma, and alpha/translucency. The 24-bit scheme would be eight bits each of RGB. I plan to feature at least three resolution modes (288x224, 576x448, 816x632) in a 7:9 aspect ratio. This is a classic arcade ratio used by the likes of Namco, Sega, Taito, and Irem. It also allows for fairly eaven Video RAM calculations, and I can manage a full 24 bit chunky pixel bitmap on the highest resolution for only 1.5 MB. As an extra bonus, these resolutions minimize interpolation problems In terms of graphical assets, I would like at least 32 SILVER object generators and 96 PENNY sprite engines. The questions become, how many LUTs and other FPGA assets do these features consume each, and how much Video RAM is needed to make use of them. The answer to the latter for SILVER object generators is fairly straightforward: In the original spec, they were, at 8-bit color depth per pixel, 1/8 the screen width and the whole screen height, which at that color depth equals 31.5K@576x448 resolution, so double or triple that at higher bit depths. PENNY sprites, however, are rather more variable in function and size, though each, according to the original spec, has 83 possible frames of motion. Display_Functionality.pdf OMNI-Memo_OCT-20-1983.pdf PENNY_SCHEMATIC..pdf PENNY-Semiconductor_Info.pdf PENNY-OCT83.pdf PLAN_January-23-1984.pdf Programming_Vivian.pdf Rainbow_Gold_Chip-Specifications-28OCT83.pdf Rainbow_Silver_Chip-Specifications-23JAN84.pdf SPEC_January-13-1984.pdf THEORY_March-9-1984.pdf VIVIAN_SPECS-January-16-1984.pdf VIVIAN-Semiconductor-Info_January-8-1984.pdf
  8. Once upon a time, starting around 1980, the Atari Semiconductor Group, the advanced R&D arm of an Atari then under control of Warner Bros. began brainstorming and then developing computer chipsets for the follow-up, if not not the linear backward-compatible successor to the Atari 8-bit series, as well as provide the hardware platform for Atari's Coin-Op division for years to come. While the original plan was to use the Motorola 68000 as the main CPU, the original chipset was designed and engineered to be CPU agnostic, in case new and better CPU instruction sets and cropped up between the beginning of the project and its fruition. Then Jack Tramiel bought Atari, and threw out all that work in favor of the project created by his own pet engineer Shiraz Shivji, creator of the Commodore VIC-20 and 64, the Atari ST. The engineers working on what had been Projects RAINBOW/SIERRA and OMNI scattered to the four winds, ending up in places such as Hewlett=Packard, Digital Equipment, Silicon Graphics, and Sharp (which would release the X68000 three years later)! Twenty years later, Curt Vendel, of the Website Atari History Museum would begin collecting notes and data surrounding those projects from primary sources and publishing them on his website. There have been several retro-computing efforts in recent years based on the products of Commodore and Apple (A non-exhaustive list would include not just the Commander X16, but also the C256 Foenix, the MEGA65, {better followups to the 64 than the 128}, the Apollo Vampire {Amiga AGA followup that should have been but never was}, and the Replica 1 {Apple I Recreation}.). I think it's high time that Atari-based victims of thwarted destiny got in on the action. I am creating this thread and placing these posts here in the Commander X16 forum because I can find no other place to put them. The Atari Age forum community is uninterested because if there are any surviving prototypes of systems, they have not seen the light of day in a long time, if ever, while the MISTer FPGA community is only interested in systems that have software actually written for them, of which the only things still locatable are three or five (depending on how you count them) chiptunes for a beta version of AMY.* At the moment, these notes constitute a what-if fantasy, that I am trying to bring to the level of plausibility in order to (one day) turn into a salable product, if I ever strike it rich or can at least (legally) raise sufficient capital. The only truly non-negotiable components are graphics chips themselves and their necessary Video RAM. Everything else: the CPU (within certain limits), the supporting sound chips#, I/O controllers, and even the form factors themselves are (at the moment) are all up for grabs. The original .pdf copies of these documents came from the Atari History Museum website. Unfortunately, Curt Vendel, the maintainer of that site, passed away around this time last year of undisclosed causes., meaning that, in all likelihood, no more notes on the Projects RAINBOW and OMNI chipsets will ever see the light of day. The website’s news page still works, but that’s because it’s a mirror on Facebook. The Atari History Museum stopped working just last week, exactly why has not been stated even on that aforementioned Facebook page. The copies of these documents I obtained are the from latest available mirrors I could find from the Internet Wayback Machine. I am going to reserve specific posts at the beginning of this thread so that I can fill in details of this project on the first page at my (relative) leisure. While I do plan to add a poll at some point to this thread, not all of my questions for this project will go up on it; the questions that don’t are questions of (estimated) fact, not solicitations of opinion. I chose this name for my project because the "Hibana" is the other Japanese pronunciation of the kanji meaning "Atari" in the term "Sekka no Atari," and because Spectrum, Rainbow, and Prism have already been taken as product names for computer hardware, "Main Sequence" being a reference to the Main Sequence of the Hertzsprung-Russel Diagram Notes: *: “Mary Had a Little Lamb” and “Good King Wenceslaus,” both in two different keys, and “Daisy Bell.” #: If it turns out that AMY is simply too difficult or too expensive to offer proper implementation for, I have a “Plan B,” but that can wait until we get to the sound chip post for me to fully explain.
  9. In addition to these things, I'd like to add a few more things to the necessary specification: Reserved words to handle sprite frames and tiles, and syntax (and possible garbage collection) to handle (re)loading of CLUTs without having to resort to a whole bunch of VPEEKs and VPOKEs. Reserved words to handle access to the PSG and Yamaha YM2151's sound channels and dynamic file linking to handle direct access to the YM3012 DAC and the PCM channel.
  10. Hmm... I wonder what it would sound like if you used the YM2151 for brass and strings, the geometry synthesis channels for light woodwinds (flutes and oboe) and simple percussion (snare and base drums) and the PCM channel (with regular garbage collection) for clarinets, saxophone, cymbals, bongos, and timpani? Or would more of the woodwinds need to be sent to the geometry channels?
×
×
  • Create New...

Important Information

Please review our Terms of Use