tcdev

Xevious has been on my to-do list for many, many years. And I'm starting to get close to the point where I'm actually going to start it. So if this isn't finished by 2030, I might actually beat you to it!!!

I'm curious to know why it has stalled. By all reports it was all-but-complete quite a while ago and there's clearly a lot of demand for it. Guess I'll just have to make a Neo Geo version then...

Hope not, because AFAIK I am on the pre-order list...

I've written 65816 ASM as well. Switching between 8<->16 bit chews up cycles and whatever 'advantage' the 65816 had over the 6502 for controlling POKEY chips is looking less and less...

Yeah but the issue is that you're now only using some of the available cycles to do useful stuff... so there's little advantage over using a 6502...

Slightly off-topic but if anyone wants to play the voices from Atari's arcade Star Wars machine... Data is contained in MAME ROM "136021.107" Here is a list of start and end addresses for the voice data. Since the ROM loads at address $4000 in 6809 address space, the offset within the ROM is just <address>-$4000. 4062-419B ; use the force luke 419C-4240 ; remember 4241-42FB ; i'm on the leader 42FC-4435 ; the force is strong with this one 4436-4576 ; red 5 standing by 4577-46C2 ; this is red 5 i'm going in 46C3-4802 ; r2 try to increase the power 4803-48DF ; you're all clear kid 48E0-49D5 ; let go luke 49D6-4A58 ; (darth vader's rasping) 4A59-4B37 ; yahoo 4B38-4C49 ; i have you now 4C4A-4DB9 ; look at the size of that thing 4DBA-4F30 ; stay in attack formation 4F31-502D ; the force will be with you 502E-50A6 ; always 50A7-51A3 ; (bleeps) 51A4-52C7 ; (wookiee growl) 52C8-54C8 ; i'm hit but not too bad, r2 see what you can do with it 54CD-557C ; i've lost r2 557D-5746 ; great shot kid that was one in a million 5747-580F ; i can't shake him 5810-58E4 ; luke trust me

Having 2 chip-select signals has nothing to do with having multiple POKEYs in a system; it's to simplify glue logic for the system designer, especially when the chip-select logic has two inputs, or being able to select either positive or negative logic without adding another inverter to the circuit. Just like any other device, you can hook as many POKEY chips up to a CPU as you desire. The chip-select pin on each is driven by address decode circuitry that is part of the system design, not the POKEY itself.

Actually the 65816 would be quite unsuited to the POKEY. In native mode the 65816 is unable to byte-address memory, being restricted to two 8-bit accesses to sequential addresses. It does have an 8-bit access mode, but then you're crippling it down towards the 6502 again.

Absolute rubbish.

The (6502/6809) main CPU in the Atari vector arcade games build a "display list" in shared memory that consists primarily of VECTOR commands and calls to vector ROM routines (that consist of VECTOR commands). Once a complete "frame" has been described, the CPU hands it over to the AVG for actual display on the monitor, then gets on with the business of building the display list for the next frame. So the main CPU doesn't have to actually render any vectors itself. The AVG in the arcade machines processes the "display list" of vector commands and controls the beam on the monitor to draw the vectors. It is a simple "processor" with a handful of special commands, either drawing or execution flow (JSR, JMP, RTS, HALT). The so-called "math box" used in the games assist the main CPU with matrix arithmetic for 2D and 3D transforms. These calculations would be required whether the display is vector, or raster (with the same graphics rendered). The math box has a PROM which defines a dozen or so subroutines that chain together a few simple operations (think micro-code in a CPU) to provide more complex operations, like a 3x3 matrix multiply. The interface is, again, a block of shared memory. FWIW A single 6809 in Star Wars controls the TMS5220 and 4x POKEY chips. The TMS5220 sample data is fed byte-by-byte by the 6809 whilst it's also doing POKEY sound. 2 POKEYs are used for FX, the other 2 for music.

Wow. How is it that I didn't know about this? Oh, it must be because I don't (yet) have a Jaguar. Well, this game is going to change that. I spent the best part of my Computer Science degree playing Xevious in the uni arcade. I was never quite as good as my mate, who could last for several hours, but I did manage to reach the end of the map a few times (the dips were set to continue from the start) and clock the score once or twice (sadly, unlike my mate, not more than once in the same game). Fun fact, your extra Salvalou go 8,9,A,B,C... my mate had 'W' when it hit the right edge of the screen. BTW there are quite a few more hidden citadels than is documented on the net, and I used to know where every single one of them was. Used to. I own a (bootleg) Xevious arcade PCB and of course Namco Classics Vol 1. I started to reverse-engineer the original arcade ROMs many, many years ago with the intention of writing a MAME driver, but was beaten to the punch. I did, however, end up writing the Namco Classics MAME driver! Fast-forward about two decades and having made some good progress on an FPGA emulation, I set it aside to pursue other projects and - bam - beaten again. Xevious is hands-down my favourite arcade game. These days I spend a lot of my hobby time reverse-engineering retro games and porting them between platforms. Xevious is on my to-do list, most likely targeting the Neo Geo. I'm curious to know whether this port is a direct translation of the original Z80 code, some sort of hybrid emulation, or done purely from observation using ripped graphics? All my ports are direct translation from original assembler code. It's a long hard slog but the end result is 100% accurate. Right now I'm doing Asteroids for the IIGS/Coco3 and possibly others. Anyway, enough rambling. It goes without saying that I'd like to be on whatever list exists for pre-order. And now I'm going to go an check out development resources for the Jaguar. Maybe I can target one of my existing ports to it? Apple II Lode Runner or ZX Spectrum Knight Lore on the Jaguar, anyone? TLDR; I'd like to be on the pre-order list please!

This is probably the biggest impediment to emulating the Neo Geo; this and the relatively large memory devices required on no less than 5 different buses. For simpler systems with modest requirements, modern FPGAs are likely to have sufficient RAM on-chip for some of the memory devices. In these cases the number of buses is almost inconsequential. A lot of 8-bit arcade games, for example, require no external RAM at all on later generation FPGAs; these games typically have video, attribute and CPU RAM sizes that are measured in 10s of kB at most. It's generally the (even 8-bit) microcomputer emulations that require external (S)RAM on "hobbyist" FPGAs, and of course later generation arcade games/consoles. Some systems can tolerate some latencies on some buses (eg. 68K) and still run "correctly", though arguably extending the latency beyond the original design specifications affects the accuracy of the emulation. Other buses, such as video memory, cannot tolerate any latencies at all. However in these latter cases, it is sometimes possible to pre-fetch into a cache since the access pattern is known. Again, this will arguably affect emulation accuracy. But in general, yes, multiple buses equates to multiple headaches for the emulation implementer.

Reading an entire "word" is inconsequential and has no down-side to performance or otherwise, it is simply masked in the controller. Given that memory is designed for maximum throughput, it would be a monumental drawback to require that entire words be written to the RAM. SDR/DDR have DQM/DM signals which are effectively byte enables for write data. So no issue there. There shouldn't be an issue using 100% of the RAM for emulated systems. 8/16-bit data buses can easily be accommodated by a mux on the data bus and shifting low-order address bits into DQM/DM signals, for example. Plenty of 8-bit emulations doing that already with 16-bit FLASH and/or SRAM. FYI here is a good explanation of how SDR/DDR works.

Nice - thanks for releasing the source!

The main reason for this is the complexity of the designs - in particular the custom ICs used in the design. There is no easy way to reverse-engineer the workings of a custom IC, especially ones as complex as those used in modern consoles. The only feasible approach has been a black-box reverse engineering and/or so-called high-level emulation at a known (well-specified) level such as an OpenGL API layer. Compatibility issues arise due to bugs/nuances of the particular implementation being unknown to the emulator authors. Those that "criticise" such efforts are certainly unable to contribute anything useful to the process and rightly ignored. On the flip side there are some advantages to a high-level approach, such as being able to generate higher-resolution displays, at the expense of accuracy. At the very least, it's a stepping-stone towards more accurate implementations and shouldn't be discouraged. You only have to look at the progress of MAME to appreciate that. You may be interested to know that portions of the N64 were implemented in Verilog. If one were to find themselves in the possession of the Verilog source, then perhaps we could start having the discussion about FPGA implementations not being emulations.