We saw that EmuTOS works fine on Vampire, using Amiga hardware. Next obvious step is to add Atari hardware implementation in the Vampire FPGA, to allow more Atari programs to work, including hardware-banging software like games and demos. Gunnar already shown interest to do that. Some Atari hardware parts are easy to implement, some are not. To get a complete ST in Vampire, the easiest way is to get in touch with people who already implemented full ST in FPGA: - Wolfgang Förster who created the Suska board - Till Harbaum who created the MIST board I'm sure their work could be merged to Vampire (or the opposite), just ask them. Before getting a full ST in Vampire, I believe it would be *easy* with *minimal* effort to get some simple Atari demos working. The idea is to load such programs with EmuTOS for Amiga, then, just before jumping to the user program, EmuTOS could enable "ST mode" by writing to a new Vampire register. What needs to be done for minimal ST mode on Vampire: 1) A new register to switch from Amiga to ST mode. Mandatory to cope with different interrupts. 2) Map $00ff0000-$00ffffff to special Atari I/O space in the FPGA. This could even be RAM for first tests, that would be good enough. 3) Map $ffxxxxxx addresses to $00xxxxxx. This is because Atari software accesses I/O space either with $ffxxxx or $ffffxxxx.w. This doesn't matter on a 24-bit address bus, but on 32-bit address buss that matters. 4) Add support for Atari interleaved bitplanes to SAGA. Gunnar told me he had already made tests with that. 5) Add support for ST-Low video mode in SAGA. Virtually all ST games and demos use that mode. It is 320x200, 4 planes (16 colors). Refresh rate is preferably 50 Hz (for European games/demos). Can also be 60 Hz by writing to a register, but not important for first tests. 6) How hardware determines the video base address, let's say $AABBCCDD: - AA is always 00. Screen buffers can be anywhere in ST-RAM (first 14 MB of address space). - BB is read from byte $FF8201 (Video base high) - CC is read from byte $FF8203 (Video base medium) - DD is always 00 on ST (additional register exists on STe) Implement the 2 above byte registers (could be simple RAM), then software can set the video address. 7) Implement palette registers There are 16 WORD registers located at $FF8240. First word is color 0 (also used for borders), second one is color 1, etc. Each word uses format $RGB. Range is from $000 (black) to $777 (white), which means 512 possible colors. High bit of each nibble is ignored on ST (only used on STe as additional LSB for 4096 colors). 8) Disable Amiga interrupts. They conflict with Atari ones. 9) Enable Atari VBL interrupt. It is 68000 level 4 interrupt, using vector at $70. It is used by programs for display synchronization. 10) Add minimal stub for YM-2148 soundchip. Virtually all games and demos write directly to it. You don't need to implement the actual chip, just ensure that BYTE writes to $FF8800 and $FF8802 don't produce something bad. 11) Add minimal stub for IKBD (intelligent keyboard). It is the device which handles keybord/mouse/joysticks. Just ensure that BYTE address $FFFC02 can be read, and returns preferably 0 to avoid software think some key is stuck. The above list is really small, but from the top of my head, I think this should be enough for a first real-world test with simple existing demos. It should be very easy to implement for an experimented VHDL developer. So, Gunnar, go ahead :-)
|