My initial task tonight was to set up an emulation environment for the II/IIGS and ensure that I could boot arbitrary disk images; ultimately that will be my Asteroids disk. My emulator of choice is MAME and for this exercise I downloaded the latest version, v0186.
Knowing next-to-nothing about Apple II DOS variants, I did some quick reading of some historical and high-level technical details and decided that it would be useful to be able to boot and work with both DOS (v3.3) and ProDOS 8 (v2.0.3 & v2.4.1) disks. It may interest some to know that only last year, ProDOS 8 received an (unofficial) update, the first since 1993!
Now that I was able to boot both DOS and ProDOS in Apple IIe & IIGS emulations under MAME, the next issue was getting Apple II executable files from the host OS (Win7) into the aforementioned .DSK files. Two options that revealed themselves with little effort on my part were CiderPress and MAME's own imgtool, although the latter only seems to support ProDOS disk images. Though I haven't actually performed an import just yet, I'm satisfied that this process will be straightforward enough.
The last - or rather first - step in the chain is producing the executable itself. Given past experience with retro development there's no question that I will be cross-assembling, and there's a handful of solutions in this regard. Initially I was keen to stick with AS6500, even if it meant writing my own utility to convert the binary output to an Apple II executable file (as I have done in the past for the TRS-80), or even extending ASLINK to do so as Boisy Pitre has done for the Coco, but after further deliberation and considering time constraints I've decided to at least start with AS65/LD65, the assembler and linker respectively from the now defunct CC65 package.
So that ties down the first iteration of my development environment.
Hopefully next session I can write a simple hello world program for the Apple II, assemble and link it with AS65 & LD65, copy it to a DOS 3.3 .DSK image file with CiderPress, and boot it under Apple IIe emulation on MAME.
Then I'll be half-way there, right?
Wednesday, 14 June 2017
Saturday, 10 June 2017
A tale of two CPUs
Not much progress... well, none to be exact... on the reverse-engineering front but I have been researching IIGS architecture and development.
The plan for a first-pass demonstration is to leave the 6502 code more-or-less intact, changing only what is required to get it running on the IIGS. Aside from possibly changing some addressing, the only other changes that come to mind immediately are the interrupt, and handshaking with the digital vector generator (aka DVG).
The result of the above should be an area of IIGS memory that is periodically updated with a new display list for the DVG.
The intention then is to implement a crude emulation of the DVG, or more precisely, an emulation of what the DVG is doing on Asteroids, that reads the display list and renders to the IIGS super hires display. I'm not planning on drawing vectors on the screen, but rather using a crude lookup to determine what the DVG is supposed to draw, and then display pre-rendered bitmaps at the appropriate screen location. This is possible only because most of the objects are actually rendered via subroutines in the DVG ROM; once I know the subroutine address, I know what object is being rendered.
Once all that is going, there's plenty of work to do to optimise the whole process by more tightly integrating the main code with the rendering code. I have some ideas about that already.
My conundrum now is whether to develop the rendering routines in native 65C816, or remain in emulated 6502 mode. I'm leaning towards the former, but it does introduce some complexities to the process, such as assembling effectively two completely separate programs, for different CPUs. And likely different assemblers, as I'd probably stick to AS6502. OTOH, it will avoid the addressing limitations, and some of the slowdowns, of remaining in 6502 mode. Not to mention, well, 6502...
Time is ticking towards WOzFest so I'd like to get a start on this sooner rather than later. I still need to sort out the emulator I'll be using (preferably MAME), and exactly how to go about executing a binary built from a generic assembler on an emulated IIGS. Guessing I'll be learning something about Ciderpress soon enough.
The plan for a first-pass demonstration is to leave the 6502 code more-or-less intact, changing only what is required to get it running on the IIGS. Aside from possibly changing some addressing, the only other changes that come to mind immediately are the interrupt, and handshaking with the digital vector generator (aka DVG).
The result of the above should be an area of IIGS memory that is periodically updated with a new display list for the DVG.
The intention then is to implement a crude emulation of the DVG, or more precisely, an emulation of what the DVG is doing on Asteroids, that reads the display list and renders to the IIGS super hires display. I'm not planning on drawing vectors on the screen, but rather using a crude lookup to determine what the DVG is supposed to draw, and then display pre-rendered bitmaps at the appropriate screen location. This is possible only because most of the objects are actually rendered via subroutines in the DVG ROM; once I know the subroutine address, I know what object is being rendered.
Once all that is going, there's plenty of work to do to optimise the whole process by more tightly integrating the main code with the rendering code. I have some ideas about that already.
My conundrum now is whether to develop the rendering routines in native 65C816, or remain in emulated 6502 mode. I'm leaning towards the former, but it does introduce some complexities to the process, such as assembling effectively two completely separate programs, for different CPUs. And likely different assemblers, as I'd probably stick to AS6502. OTOH, it will avoid the addressing limitations, and some of the slowdowns, of remaining in 6502 mode. Not to mention, well, 6502...
Time is ticking towards WOzFest so I'd like to get a start on this sooner rather than later. I still need to sort out the emulator I'll be using (preferably MAME), and exactly how to go about executing a binary built from a generic assembler on an emulated IIGS. Guessing I'll be learning something about Ciderpress soon enough.
Tuesday, 30 May 2017
Between a rock and a hard place
OK, without further ado, the mystery project is... Asteroids - the arcade version of course!
Nobert Kehrer did much the same first for the Atari 800XL, then for the Commodore 64. So I won't be breaking any new ground, but rather leveraging off the work done by Lonnie Howell in the original reverse-engineering effort and of course Norbert's so-called emulators. I've managed to advance Lonnie's work so that - as it stands - a good portion of the code is now commented, and Norbert has been kind enough to answer technical questions and even permit me to use his rasterized graphics data.
I'm confident now that I know enough already about Asteroids itself to port to other platforms; the task now is to learn enough about each of the target machines to effect the ports.
I've decided that I'll tackle the Apple IIGS first - a machine I currently know very little about. I've done some reading up on it tonight, and learned at least that it's possible to use the enhanced graphics modes (with sane memory maps) with the CPU in 'emulation' (6502) mode at 2.8MHz. 6502 mode does, however, place some restrictions on both resources and performance, so it remains to be seen whether or not I do indeed need to switch to native 65816 mode.
I was hoping to keep the code as legacy 6502 for two reasons. One, it negates the need to port the bulk of the code to a new CPU and two, it would leave an option to produce a version for Apple II/+/e machines with an accelerator card, requiring only rework of the graphics routines. Only time will tell...
The main impetus behind doing the IIGS port first is the fact that the next WOzFest meeting is slated for a IIGS theme and will coincide with the 2017 KansasFest (possibly with a live hookup). So I thought being able to demonstrate a new IIGS game on the day would be pretty cool.
As for Coco3, that's probably a lot more straightforward for me as I've done three ports to it now (Lode Runner, Knight Lore and Space Invaders), but of course requires translation from 6502 to 6809.
At first glance, having a 6809 version would make the Vectrex an obvious target, but unfortunately the stock console has insufficient RAM. However there exist several multi-carts that include additional system RAM, so a port may yet be worthwhile. The technical challenge there is to squeeze out enough performance from the 1.5MHz 6809 to emulate both the 1.5MHz 6502 and the Atari Digital Vector Generator (DVG). Perhaps a tall ask, but relatively little effort for a proof-of-concept demo at the least.
 |
| Image from playertheory.com |
Nobert Kehrer did much the same first for the Atari 800XL, then for the Commodore 64. So I won't be breaking any new ground, but rather leveraging off the work done by Lonnie Howell in the original reverse-engineering effort and of course Norbert's so-called emulators. I've managed to advance Lonnie's work so that - as it stands - a good portion of the code is now commented, and Norbert has been kind enough to answer technical questions and even permit me to use his rasterized graphics data.
I'm confident now that I know enough already about Asteroids itself to port to other platforms; the task now is to learn enough about each of the target machines to effect the ports.
I've decided that I'll tackle the Apple IIGS first - a machine I currently know very little about. I've done some reading up on it tonight, and learned at least that it's possible to use the enhanced graphics modes (with sane memory maps) with the CPU in 'emulation' (6502) mode at 2.8MHz. 6502 mode does, however, place some restrictions on both resources and performance, so it remains to be seen whether or not I do indeed need to switch to native 65816 mode.
I was hoping to keep the code as legacy 6502 for two reasons. One, it negates the need to port the bulk of the code to a new CPU and two, it would leave an option to produce a version for Apple II/+/e machines with an accelerator card, requiring only rework of the graphics routines. Only time will tell...
The main impetus behind doing the IIGS port first is the fact that the next WOzFest meeting is slated for a IIGS theme and will coincide with the 2017 KansasFest (possibly with a live hookup). So I thought being able to demonstrate a new IIGS game on the day would be pretty cool.
As for Coco3, that's probably a lot more straightforward for me as I've done three ports to it now (Lode Runner, Knight Lore and Space Invaders), but of course requires translation from 6502 to 6809.
At first glance, having a 6809 version would make the Vectrex an obvious target, but unfortunately the stock console has insufficient RAM. However there exist several multi-carts that include additional system RAM, so a port may yet be worthwhile. The technical challenge there is to squeeze out enough performance from the 1.5MHz 6809 to emulate both the 1.5MHz 6502 and the Atari Digital Vector Generator (DVG). Perhaps a tall ask, but relatively little effort for a proof-of-concept demo at the least.
Monday, 29 May 2017
The home stretch on the reverse-engineering
Good progress tonight now that all-but-a-few variables have been labelled!
If I had to guess, I'd say the code annotation is now 75-80% complete. Hopefully only a few more sessions until it's done. There's a few details I need to confirm via experimentation with MAME but it all seems to make sense for the most part.
Even right now, there's easily enough information to start on any of the ports.
And more good news; the author of the original 'emulator' has supplied and given me permission to use his graphics data in my ports, which will only make my job easier!
If I had to guess, I'd say the code annotation is now 75-80% complete. Hopefully only a few more sessions until it's done. There's a few details I need to confirm via experimentation with MAME but it all seems to make sense for the most part.
Even right now, there's easily enough information to start on any of the ports.
And more good news; the author of the original 'emulator' has supplied and given me permission to use his graphics data in my ports, which will only make my job easier!
Friday, 26 May 2017
Variables disclosed as I reconsider the Vectrex
After some discussion with jmk (which can be seen in the comments of the previous post) I'm now reconsidering a Vectrex port. Given there exist a few multi-carts with RAM expansions, I think there's still enough of an audience to make the port worthwhile, especially considering I'll have a 6809 core for the Coco3 - even if it is just a 'proof of concept' playable demo.
That decision aside, just as I was getting bogged down trying to determine the usage of the player data RAM blocks, I notice that much of the work has (recently?) been done for me on a well-known reverse-engineering website. It really is getting to the point where I should reveal the project...
But for now, I'll take this new information and persist with the reverse-engineering whilst the code is relatively self-explanatory. If and when I do hit another brick wall, I'll turn my hand to starting one or more of the ports. I have a deadline for the IIGS port at least...
That decision aside, just as I was getting bogged down trying to determine the usage of the player data RAM blocks, I notice that much of the work has (recently?) been done for me on a well-known reverse-engineering website. It really is getting to the point where I should reveal the project...
But for now, I'll take this new information and persist with the reverse-engineering whilst the code is relatively self-explanatory. If and when I do hit another brick wall, I'll turn my hand to starting one or more of the ports. I have a deadline for the IIGS port at least...
Wednesday, 17 May 2017
No Vectrex port this time 'round.
Well, that'll teach me - again - not to get too far into a project without checking all the details for intended porting projects! Turns out the Vectrex isn't going to have enough RAM for this port, even in 1 player mode. Wondering if it's possible to design a cart with some SRAM - the connector does have a RW# signal... oh well, it was never the primary target anyway...
As I mentioned, reverse-engineering is getting to the nasty stuff (nitty gritty) and I'm considering commencing the actual porting. My targets now include Coco3 (6809) and Apple IIGS (6502/65816), so I now need to decide which avenue to take. Would be nice to have the IIGS version at least running - if not finished - for the next WOzFest, but given my limited time recently it's a tall order!
As I mentioned, reverse-engineering is getting to the nasty stuff (nitty gritty) and I'm considering commencing the actual porting. My targets now include Coco3 (6809) and Apple IIGS (6502/65816), so I now need to decide which avenue to take. Would be nice to have the IIGS version at least running - if not finished - for the next WOzFest, but given my limited time recently it's a tall order!
Monday, 15 May 2017
Slow going, time to start porting?
Slowly, slowly chipping away at the code; not that I've had much time to spend on it lately, but it's also slow going as all the low-hanging fruit has been... commented!
I'm starting to think that it's time to start on the port, and perhaps work in parallel with the rest of the reverse-engineering. This approach worked reasonably well with Knight Lore, and I've certainly got all the hardware figured out to a point to allow me to do so.
If so, then I'll start with the 6809 port - but not for the Coco3!
I'm starting to think that it's time to start on the port, and perhaps work in parallel with the rest of the reverse-engineering. This approach worked reasonably well with Knight Lore, and I've certainly got all the hardware figured out to a point to allow me to do so.
If so, then I'll start with the 6809 port - but not for the Coco3!
Subscribe to:
Posts (Atom)