32 replies to this topic

[DanBoris]

I don't have an objection to including simple header features when a game is actually going to be released that needs it, but I don't like the idea of having "infinitely configurable" hardware defined in the headers. You are talking about adding bits for flexible memory, but what if I want the flexibility to put a POKEY anywhere in memory I want it, or maybe two POKEYS, etc, where would you draw the line. The header could end up getting very complex.

I think the emulator authors can build that kind of flexibility into the emulator so developers can play with various configurations that a cart might support, and then add it to the header when they have settled on the scheme they want to use.

Dan

GroovyBee, on Tue Apr 6, 2010 3:34 PM, said:

Its ideal for Beeb ports. Typically Beeb games are 16K or less (it depends on the graphics mode used in the original). The port of Beeb Tempest now uses the new header format. If I do any other Beeb ports they'll most likely use the new header format too.

In my opinion continually forcing homebrew developers to use the "old" cart models is going to hamper development on the system.

I have lots of plans for the 7800 some of which will most likely need header file changes to correctly configure the emulator.

[GroovyBee]

DanBoris, on Tue Apr 6, 2010 4:25 PM, said:

I think the emulator authors can build that kind of flexibility into the emulator so developers can play with various configurations that a cart might support, and then add it to the header when they have settled on the scheme they want to use.

In practice change requests only work if the emulator is actively developed. ProSystem v1.x isn't actively developed at the moment . Its only being ported across to other platforms e.g. Wii, PSP etc. I made some suggestions in May last year for some changes that I'd find useful (and maybe other programmers would too) and I eventually gave up and implemented them myself in a personal version of the source code. I'm not blaming anybody because real life gets in the way and projects fall by the wayside.

I'm going to be producing two builds of the emulator. One for developers that will have some simple debugging facilities like the ability to display the number of MARIA cycles per zone, logging/capturing writes to specific areas of memory, displaying memory, a debug port etc. The other version will not have those features enabled and will be for mainstream use.

[krewat]

I love this solution. Given that there is active development in the Atari 7800 realm, and that it is very possible to put real actual RAM at these addresses in a real active cartridge, AND I can actually see a reason to have so much RAM available, AND that it's not necessarily a "super cart" that would get RAM at $4000, I think this solution is perfect. (run on sentence much?)

ESPECIALLY as it only affects .a78 rom images, specific to the Atari 7800, and no other machine.

[DanBoris]

Ok, I'm just giving my opinion as the original creator of the header format. I am not going to try to stop anyone from doing this if they really want to.

As for an emulator with a debugger, I have always wanted to take EMU7800 (http://emu7800.sourceforge.net/) and combine it with all the debugging capabilities of my 6502SIM simulator to make a really nice emulator for developers. Unfortunately it's one of those project I just never seem to get around to doing .

Dan

GroovyBee, on Tue Apr 6, 2010 4:51 PM, said:

In practice change requests only work if the emulator is actively developed. ProSystem v1.x isn't actively developed at the moment . Its only being ported across to other platforms e.g. Wii, PSP etc. I made some suggestions in May last year for some changes that I'd find useful (and maybe other programmers would too) and I eventually gave up and implemented them myself in a personal version of the source code. I'm not blaming anybody because real life gets in the way and projects fall by the wayside.

I'm going to be producing two builds of the emulator. One for developers that will have some simple debugging facilities like the ability to display the number of MARIA cycles per zone, logging/capturing writes to specific areas of memory, displaying memory, a debug port etc. The other version will not have those features enabled and will be for mainstream use.

[gdement]

GroovyBee, on Tue Apr 6, 2010 4:51 PM, said:

I made some suggestions in May last year for some changes that I'd find useful (and maybe other programmers would too) and I eventually gave up and implemented them myself in a personal version of the source code. I'm not blaming anybody because real life gets in the way and projects fall by the wayside.

Sorry that I didn't get those changes done. I really did intend to do them, but as time dragged on, at some point I should have made a firm decision to either get 'er DONE, or else let you know it wasn't happening. I should have kept in better communication about that.

Quote

I'm going to be producing two builds of the emulator. One for developers that will have some simple debugging facilities like the ability to display the number of MARIA cycles per zone, logging/capturing writes to specific areas of memory, displaying memory, a debug port etc. The other version will not have those features enabled and will be for mainstream use.

2 builds would work, but any reason why these features couldn't just be enabled using a flag in the .ini configuration?

[GroovyBee]

gdement, on Wed Apr 7, 2010 6:27 AM, said:

2 builds would work, but any reason why these features couldn't just be enabled using a flag in the .ini configuration?

Basically the code isn't there to be enabled. ProSystem can now build release, debug and debug developer versions of the code.

[GroovyBee]

In order to support Curt's expansion module I'm also proposing the following for V2 of the a78 header :-

Byte index 63 - Expansion module
0x00 - No expansion module (default on all currently released games).
0x01 - Expansion module required.
0x02 to 0x80 - To be defined.

Whatever hardware specification the expansion module ends up at with regards to RAM, POKEY or feature XYZ, ProSystem will support it. Games will have to enable the features they are interested in, exactly like they would do on real hardware.

Would support for dual POKEY be of interest? By that I mean one in the cart and one in the expansion module? Or maybe even two in the expansion module.

[Bruce Tomlin]

GroovyBee, on Mon Apr 5, 2010 7:02 AM, said:

Obviously some addresses would clash with the 7800's internal RAM. To map the RAM you want you just logical OR the values above together. So in Arts example of RAM at $4000 to $5FFF he'd need the following :-

00000000 01111111 10000000 00000000

Or you could just re-use the bits referring to standard RAM (as well as the $0000 block) for another feature.