Jump to content

Kalvan

Members
  • Posts

    70
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Kalvan

  1. I'm still a big fan of the number pad, but otherwise, not bad. It looks like the late-80s Dell or Zenith Data Systems MSX Turbo-R machine that never was but woulda-coulda-shoulda been. Uh, does Madame Allaire have plans for the blank key between Z and left Shift?
  2. An example of this sort of thing is something like Sega's Afterburner. We have PCM samples for trumpets, snares and cymbals, and the medium and high strings on the electric guitar solo that plays during the ground strafing bonus stages. If we time things exactly, with the samples, we may be able to put any two of them through the PCI channel, using the FIFO, since the SegaPCM's channels are 12 bits wide each, and most samples were more like 8 bit wide. That leaves one of those things for either Logical Channel 7+plus the DAC, or else we try to paper it over with at least two FM channels of the YM2151 and remix the rest of the FM track to minimize the loss elsewhere. We can send the drums, or at least the snares through the Geometry channels, like the PC Engine/TurboGrafx 16 version, but it won't be quite as good as arcade quality. It's a suboptimal solution, but rather less so than the Non-32X Genesis version of Afterburner II was forced to go with, since the only Genesis cartridges with add-in chips were Virtua Fighter, Virtua Racing, Daytona USA, Shining Force II, and Mortal Kombat II and III. Of course we can always bite the bullet, so to speak, and remix the soundtrack as if it were a Chinese or Brazilian knockoff forced to use Capcom CPS-1 hardware. We can simply use Sharp X68000 version of the soundtrack as our basis without the addition of MERCURY and/or Roland MIDI module support...
  3. Well, between the YM2151+YM3012 and the VERA's Geometry and PCM channels, we have sufficient audio power for all of Capcom's arcade games up to the CPS-1 board, and all of Taito's arcade games up to the F1/F2 hardware. For then contemporary Atari arcade hardware up to the GX2 arcade board, it's debatable whether VERA's geometry channels can simulate a QuadPOKEY, considering the latter uses a "Comb Tooth" Sawtooth pattern for white noise, plus the whole "combining channels" thing, although the PCM Channel can definitely match the Okidata 62 series 4-bit ADPCM chips and Texas Instruments TMS5220 speech chip. Things like the SegaPCM, and Namco, Seta, and Irem wavetable chips will be harder for the Commander X16 to match directly. So, any ports of games from those companies wwill need creative use of the PCM channel and Logical Channel 7 + the DAC for the most distinct tones from those chips in those games. Also, the YM2612 only has 6 channels. Why stop at a mere perfect port of Sega Genesis and SNK NeoGeo FM audio, when you can add two more note layers (three if they're using Logical Channel 5 for PCM), especially when the X16 Kernel will have garbage collection and the overall system isn't limited to floppy disc capacities?
  4. There's no way I can attend. Could you or anyone else please point me (and the rest of us forum members who aren't on the Commander X16 dev team) to YouTube channels that have committed to filming and posting it after the event?
  5. For a real improvement, he could have used his 65000 series project for the CPU...
  6. I had originally planned to to wait until the team was ready, but what I was toying with was, depending on form factor and addressing capabilities, anywhere from one to seven unpopulated 128K RAM DIP sockets, for use as extra Video RAM. The idea is not so much to add all new modes to the hardware as to (at the customer's option) maximize the capabilities of the current modes in the FPGA. With three of those DIP sockets filled, there is enough Video RAM space for all 128 sprites at 64x64 4-bit pixels with no scanline limits, with the tilemode or bitmap depth to match, for example. Stick this version of VERA in an Atari 520/1040ST, and (in theory) you have the architectural missing link between the Apple Lisa/Macintosh XL and the first-generation Sharp X68000, hardware feature-wise, at least.
  7. Okay, I guess that would be a bust unless the creator stuck it on a new riser domino that had room for the extra eight pins. Message sent and received. Hmm... The Atari 8-bit community has various upgrades available to its machines, but they are strictly system RAM upgrades, 65816 processor upgrades, and, with the "Veronica," HDMI/DisplayPort interface for modern discrete pixel monitors. Why not, in the spirit of this upgrade, FPGA updates to ANTIC and C/GTIA that add a bigger master palette, more colors onscreen, and especially more hardware players and missiles?
  8. Well, maybe we can continue this thread with speculation and recommendations for the add-on version for when it comes time to think about that. Obviously, for form factors, they'll need to cover the basics, which would include... 8 and 16-bit ISA, Apple II expansion slot Apple IIgs expansion slot BBC Micro Tube Interface Commodore VIC20/64/128 User Port Commodore Vic20/64/128 Cartridge Slot Commodore VIC20/64/128 VIC/VIC II/VIC IIe Socket Riser Domino MSX Expansion Cartridge Atari 800/XEGS "Big Cartridge" Slot Atar 8 Bit Serial I/O module Sinclair ZX Spectrum/Timex-Sinclair 2048-4096 Expansion Module May I also suggest dropping the PSG and PCM channels, so that they can be put on a different FPGA? That way we could split the thread into separate proposals. Possibly more latar.
  9. The biggest issue, aside from determining exactly how to interface VERA to the PET's motherboard (which in turn raises the questions of exactly which sub-model of PET and exactly what sort of monitor it currently has), is that the 6502 used in the PET has a stock clock speed no more than 1/8 that of the 65C02 in the Commander X16. Software written for the PET with a VERA on the motherboard has to to take this into account. Otherwise, there could be frame rate issues...
  10. It seems to be tripped up by the limits of a stock 6510. I wonder what would happen if the 64K version was stuck into a Commodore 128...
  11. 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.
  12. 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.
  13. 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.
  14. Here's a bump, and an update adding the support chip post and a poll.
  15. 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.
  16. 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
  17. 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
  18. 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.
  19. 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.
  20. 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