Jump to content

My New Pie in the sky Retrocomputing Project: The Hibana Main Sequence


Public preferences for the Hibana Main Sequence  

1 member has voted

  1. 1. Which direction would better work for the project?

    • MIPS+Western Design+Motorola/Freescale
    • Zilog
      0
    • Other (Please Explain in a Post)
      0


Recommended Posts

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.

Edited by Kalvan
Link to comment
Share on other sites

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

 

Edited by Kalvan
Posting the Graphics Architecture
Link to comment
Share on other sites

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

Edited by Kalvan
Link to comment
Share on other sites

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.

Edited by Kalvan
Adding CPU and other support chip info.
Link to comment
Share on other sites

I don't know enough about your ideas to know if this idea is useful to you, but I plan to (at some point) use at least pieces of the MiSTer code to build my own idea of a computer. So while they might not be interested in doing anything themselves, one can get a huge step up by leveraging existing code. So if anything you intend to do has existing solutions as part of one of the MiSTer cores, the odds are good you could use them as part of your own if the license terms are acceptable to you.

  • Thanks 1
Link to comment
Share on other sites

I don't think your opening post actually explains what you're trying to do - just that nobody cares that you're doing it.

Can you summarize what you're trying to do, in one or two sentences, in the opening post? Is this supposed to be something like an Atari ST successor?

Edited by TomXP411
Link to comment
Share on other sites

1 hour ago, TomXP411 said:

I don't think your opening post actually explains what you're trying to do - just that nobody cares that you're doing it.

Can you summarize what you're trying to do, in one or two sentences, in the opening post? Is this supposed to be something like an Atari ST successor?

Done, even if it took more than two sentences.

Link to comment
Share on other sites

Good luck.

I think the problem with hyper complicated graphics devices is that projects that maximise their usage are a *lot* of work. It's nice to have hardware with high quality quasi 3D graphics and all sorts of complex sounds and the like, but is anyone going to write for it ? 

I think Vera is about right, in that it's a sort of tarted up version of the well used TMS99x8 series. (Sometimes I think the Commander X16 isn't a modern Commodore, it's a modern MSX/Creativision)

You can get good graphics out of it, but you aren't asking a huge amount of work from an amateur to get the sound and graphics to get a game working, it's just better resolution and more colours than an early-mid 1980s 8 bit computer.

If I were to write a game I'd have to ask for help with the graphics or pinch them from things like OpenClipArt (I cannot draw *at all* - seriously it's at the 5 year old level - my sister is an amazing artist and I think she acquired the entire artistic genetic capability of me and my other sister). It's one thing to ask for someone to do a few tiles and sprites, say like PETSCII robots, and another thing to churn out shedloads of the stuff.

Sound has the same issue. If it's a few beeps and basic sound effects and maybe a little tune, it's doable.

I think we should settle for that and not try to compete with the XBoxes of the world, even the first one. Tablets and Phones show us that games do not have to be gee whiz for people to enjoy them. In some ways it's more fun trying to get a game out of an RCA Studio 2 (I wrote Pacman for it because someone said it couldn't be done ...) than it would be implementing it on C on the original PSX.

 

                    

 

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

9 hours ago, paulscottrobson said:

I'm all for it 🙂

Action isn't that great incidentally. I spent some time figuring out what's going on under the hood and what it produces. Some of it is a bit slapdash.

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.

Link to comment
Share on other sites

2 hours ago, Kalvan said:

Oh, please do tell. 

It's good for something that has to fit on a 6502. But there are limitations you can't see, like you can't have multiple structures with X and Y. Everything is static, which is a good idea for a 6502 with it's less than awesome stack,  but not great in the sort of CPUs you seem to be thinking about.

  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use