ProSystem Emulator Update?

[gdement]

You are correct on both accounts. The button mapping is backwards and since the legacy signal is not emulated properly two button games do not quite work right..

 

See this thread.

I had forgotten about that thread. The fix I did still isn't compliant with that info. It only fixes a minor coding bug with the right button, so now the code functions as it was originally intended to, but it's still probably not hardware accurate.

It doesn't recognize the different 1-button vs 2-button modes described in that thread.

 

I noticed Dark Chambers still doesn't have bombs working, and whatever was wrong with Desert Falcon might not be fixed either. Probably the mode behavior needs to be added.

[Shannon]

Yeah when I posted the link I forgot you were involved in that thread. But yes placing in the proper behavior does cause the bombs to work correctly in Dark Chambers. I did so in MESS.

[Gorf]

You are correct on both accounts. The button mapping is backwards and since the legacy signal is not emulated properly two button games do not quite work right..

 

See this thread.

I had forgotten about that thread. The fix I did still isn't compliant with that info. It only fixes a minor coding bug with the right button, so now the code functions as it was originally intended to, but it's still probably not hardware accurate.

It doesn't recognize the different 1-button vs 2-button modes described in that thread.

 

I noticed Dark Chambers still doesn't have bombs working, and whatever was wrong with Desert Falcon might not be fixed either. Probably the mode behavior needs to be added.

 

 

Nice job. It's good to have the controllers working more accurately.

 

Since you have been playing with the source, what would it take to implement

a new cart format?

 

The ideal format for games Im trying to create would be a cart with 8k RAM

at address $4000-$3FF0 and a POKEY mapped in the last 16 bytes of that area.

32k ROM is enough for the first title or two, but it would be nice to bank in more

ROM as more games can use the newer abilities that the extra RAM would afford

Maria.

Edited March 21, 2009 by Gorf

[+Mitch]

Since you have been playing with the source, what would it take to implement

a new cart format?

 

The ideal format for games Im trying to create would be a cart with 8k RAM

at address $4000-$3FF0 and a POKEY mapped in the last 16 bytes of that area.

32k ROM is enough for the first title or two, but it would be nice to bank in more

ROM as more games can use the newer abilities that the extra RAM would afford

Maria.

 

If you want to have 32K ROM + 8K RAM and POKEY; I would think you would want it laid out with POKEY from 4000-5FFF, RAM at 6000-7FFF and ROM from 8000-FFFF. That way you keep it closer to the way Atari laid it out. If you want to do bankswitching then put your fixed 16K ROM bank at C000-FFFF and your 16K ROM banking area at 8000-BFFF.

 

Mitch

[gdement]

Since you have been playing with the source, what would it take to implement

a new cart format?

 

The ideal format for games Im trying to create would be a cart with 8k RAM

at address $4000-$3FF0 and a POKEY mapped in the last 16 bytes of that area.

32k ROM is enough for the first title or two, but it would be nice to bank in more

ROM as more games can use the newer abilities that the extra RAM would afford

Maria.

Looks like this would be set up in Cartridge.cpp, and it looks simple enough but I haven't really paid much attention to that part of the code.

It would be difficult to do this well without being able to test it though.. it's probably best if you do it.

 

I'd suggest looking at what can be implemented in cartridge hardware before the emulator - adding banking schemes to the emulator should be pretty simple but it might prove impractical when you get to a real cart. I'm not sure how you'd map the POKEY to only 16 bytes, but I'm not a hardware expert.

 

 

Also, this raises an interesting question:

In the long run there could be all sorts of mapping schemes that different homebrewers would like to use or experiment with. Relatively few may actually end up being used on real cartridges, but they could start to clutter up emulators and the .a78 header format.

 

We probably need a standard way to organize experimental mapping schemes, vs production stuff. I'm not even sure if experimentals should be in a mainstream version of the emulator, but obviously homebrewers need support for whatever they're working on.

[Gorf]

Since you have been playing with the source, what would it take to implement

a new cart format?

 

The ideal format for games Im trying to create would be a cart with 8k RAM

at address $4000-$3FF0 and a POKEY mapped in the last 16 bytes of that area.

32k ROM is enough for the first title or two, but it would be nice to bank in more

ROM as more games can use the newer abilities that the extra RAM would afford

Maria.

 

If you want to have 32K ROM + 8K RAM and POKEY; I would think you would want it laid out with POKEY from 4000-5FFF, RAM at 6000-7FFF and ROM from 8000-FFFF. That way you keep it closer to the way Atari laid it out. If you want to do bankswitching then put your fixed 16K ROM bank at C000-FFFF and your 16K ROM banking area at 8000-BFFF.

 

Mitch

 

That would work fine but Im interested in getting an emulator to do it. The hardware part is a matter of

a day or two with my circuit CAD.

[Gorf]

Since you have been playing with the source, what would it take to implement

a new cart format?

 

The ideal format for games Im trying to create would be a cart with 8k RAM

at address $4000-$3FF0 and a POKEY mapped in the last 16 bytes of that area.

32k ROM is enough for the first title or two, but it would be nice to bank in more

ROM as more games can use the newer abilities that the extra RAM would afford

Maria.

Looks like this would be set up in Cartridge.cpp, and it looks simple enough but I haven't really paid much attention to that part of the code.

It would be difficult to do this well without being able to test it though.. it's probably best if you do it.

 

I'd suggest looking at what can be implemented in cartridge hardware before the emulator - adding banking schemes to the emulator should be pretty simple but it might prove impractical when you get to a real cart. I'm not sure how you'd map the POKEY to only 16 bytes, but I'm not a hardware expert.

 

 

Also, this raises an interesting question:

In the long run there could be all sorts of mapping schemes that different homebrewers would like to use or experiment with. Relatively few may actually end up being used on real cartridges, but they could start to clutter up emulators and the .a78 header format.

 

We probably need a standard way to organize experimental mapping schemes, vs production stuff. I'm not even sure if experimentals should be in a mainstream version of the emulator, but obviously homebrewers need support for whatever they're working on.

 

I could always send you a bin of something for the testing.

 

I'll have to take a look at the source when I get some time.

I think a sort of 'plug in' mode for us home brew developers would be cool.

 

Some way of allowing the developer to set the cart parameters in a text based

file that ProSystem could look for or be directed to. The emulator can then do

the POKEY decode depending on the file.

 

For example, the text file for my case would be something like...

 

32k ROM,8k RAM,1 pokey

 

ROM = 8000, 8000 
RAM = 4000, 2000
POK = 6000, 10

 

 

So if a dev wanted to have something like 16k ROM, 8k RAM, 4 pokeys, 16k ROM bank switching.

 

ROM = 8000, 4000 
BNK = C000, #banks
RAM = 4000, 2000
POK = 6000, 10
POK = 6010, 10
POK = 6020, 10
POK = 6030, 10

 

 

Of course this last one would be a large PCB unless you can FPGA or DSP emulate the pokeys.

Edited March 24, 2009 by Gorf

[+Allan]

So if a dev wanted to have something like 16k ROM, 8k RAM, 4 pokeys, 16k ROM bank switching.

 

ROM = 8000, 4000 
BNK = C000, #banks
RAM = 4000, 2000
POK = 6000, 10
POK = 6010, 10
POK = 6020, 10
POK = 6030, 10

 

 

Of course this last one would be a large PCB unless you can FPGA or DSP emulate the pokeys.

 

I have no clue so that's why I'm asking but is it possible for the 7800 to have/access more than one Pokey on a cart? That's sounds pretty cool.

 

Allan

[gdement]

So if a dev wanted to have something like 16k ROM, 8k RAM, 4 pokeys, 16k ROM bank switching.

 

ROM = 8000, 4000 
BNK = C000, #banks
RAM = 4000, 2000
POK = 6000, 10
POK = 6010, 10
POK = 6020, 10
POK = 6030, 10

 

 

Of course this last one would be a large PCB unless you can FPGA or DSP emulate the pokeys.

 

I have no clue so that's why I'm asking but is it possible for the 7800 to have/access more than one Pokey on a cart? That's sounds pretty cool.

 

Allan

 

 

Electronically I suppose it's possible, but it would take a ton of board space. The problem with the POKEY is it's huge. It contains a bunch of functions that have nothing to do with sound, but they never made a downsized sound-only version.

 

I think there's only one place on the PCB where you can fit a 40-pin chip, so that would be a problem. It would probably require a custom cart shell designed around a different PCB shape. Expensive project.

Edited March 25, 2009 by gdement

[gdement]

A while back I noticed a problem with the window position on my brother in law's computer. He has his taskbar at the top of the screen. When I ran the emulator on his computer, the window would appear underneath the taskbar, unreachable with the mouse.

It could be moved with ALT-Space, but of course that's not user friendly.

 

A few days ago I noticed the window position was also resetting to default every time you run it. This is more of a pain with dual monitors, I wanted ProSystem to launch on the 2nd monitor because I KVM the 1st to a linux box when doing 7800 code.

 

Both of these were simple fixes, but the window position reset took forever to debug. Turns out that debugging is broken when using Visual C++ 6.0 on WinXP SP2+. This sucks. If I could just set a breakpoint and watch some variables it would have been much easier.

 

========================================

Minor update to handling of the emulator's window position:

- FIXED: emulator window now opens in previously saved position, not 0,0 (console.cpp)

- changed default window position to (120, 120) instead of upper left corner. (configuration.cpp)

This prevents menu and title bar from appearing underneath some taskbar setups.

 

 

 

[gdement]

Annoying mistake - I forgot to change the version number in the file I posted previously.

The files I posted above report the wrong version and should not exist.

 

This fixes that. No changes, just the correct version "1.3c" now shown in the "about" screen.

ProSystem_13c.zip

ProSystem_1_3c_Src.zip

[Gorf]

So if a dev wanted to have something like 16k ROM, 8k RAM, 4 pokeys, 16k ROM bank switching.

 

ROM = 8000, 4000 
BNK = C000, #banks
RAM = 4000, 2000
POK = 6000, 10
POK = 6010, 10
POK = 6020, 10
POK = 6030, 10

 

 

Of course this last one would be a large PCB unless you can FPGA or DSP emulate the pokeys.

 

I have no clue so that's why I'm asking but is it possible for the 7800 to have/access more than one Pokey on a cart? That's sounds pretty cool.

 

Allan

 

 

Yup! It takes only 16 registers of memory space so you can have MANY more but the work involved...

 

But as gdement points out the board increases in size with every POKEY you add. I was thinking

this to be used as the base for the 7800 keyboard. Forget that expansion port and use the cart slot

instead. Then you can use a top mounted add on and a thru cart port. I for one would rather use

a tiny DSP to emulate a number of POKEYS. I should attempt this first on the Jaguar's DSP first....

hmmmm..... interesting.

[xZanU]

Annoying mistake - I forgot to change the version number in the file I posted previously.

The files I posted above report the wrong version and should not exist.

 

This fixes that. No changes, just the correct version "1.3c" now shown in the "about" screen.

ProSystem_13c.zip

ProSystem_1_3c_Src.zip

Thanks for this, I will download when I get home. I also have the taskbar at the top and always did ALT+SPACE > Move, this saves a step

[gdement]

After re-reading the info from Dan Boris in another thread (mentioned by Shannon earlier), and matching that up with the full 7800 schematic, I decided I was comfortable with properly fixing the controllers.

 

=========================================

2nd button now works correctly in Dark Chambers

Joystick button emulation is now much more accurate

- Distinct 1 button and 2 button joystick modes are now properly emulated (riot.cpp)

- SWCHB is now writable allowing games to toggle the button mode (memory.cpp)

- SWCHB default settings match testing on real console.

 

 

ProSystem_13d.zip

ProSystem_1_3d_Src.zip

[+Mitch]

Hey cool, glad to see that the controllers are finally emulated correctly.

 

By the way, do you know if the 64K game emulation ever got fixed? I'm too lazy to check at the moment.

 

Mitch

[gdement]

Hey cool, glad to see that the controllers are finally emulated correctly.

 

By the way, do you know if the 64K game emulation ever got fixed? I'm too lazy to check at the moment.

 

Mitch

 

Probably not, I haven't looked at that.

[Gorf]

Hey cool, glad to see that the controllers are finally emulated correctly.

 

By the way, do you know if the 64K game emulation ever got fixed? I'm too lazy to check at the moment.

 

Mitch

 

If I find some time someday I plan to look at the memory code for a bunch of reasons.

I'll look into that if I get to it.

[Curry]

ProSystem is an incredible emulator and it's so easy to set up and use.

 

I installed the update (version d) and the left and right buttons still don't work independently for Xevious. Any hope of getting them sorted out too? Thanks!

[kenfused]

ProSystem is an incredible emulator and it's so easy to set up and use.

 

I installed the update (version d) and the left and right buttons still don't work independently for Xevious. Any hope of getting them sorted out too? Thanks!

I think maybe with Xevious you have to use the difficulty switches to switch between one and two button mode.

[GroovyBee]

Double post...

Edited April 5, 2009 by GroovyBee

[GroovyBee]

After re-reading the info from Dan Boris in another thread (mentioned by Shannon earlier), and matching that up with the full 7800 schematic, I decided I was comfortable with properly fixing the controllers.

 

=========================================

2nd button now works correctly in Dark Chambers

Joystick button emulation is now much more accurate

- Distinct 1 button and 2 button joystick modes are now properly emulated (riot.cpp)

- SWCHB is now writable allowing games to toggle the button mode (memory.cpp)

- SWCHB default settings match testing on real console.

I don't think the buttons are correct in the source code. If you look in the document 7800_DevKit.pdf it tells you to perform the following :-

 lda #$14
sta CTLSWB
lda #0
sta SWCHB

So its writes to CTLSWB (at address $283) that control the dual button mode. Which makes sense because that controls the data direction of port B.

[gdement]

I don't think the buttons are correct in the source code. If you look in the document 7800_DevKit.pdf it tells you to perform the following :-

 lda #$14
sta CTLSWB
lda #0
sta SWCHB

So its writes to CTLSWB (at address $283) that control the dual button mode. Which makes sense because that controls the data direction of port B.

 

Looks like maybe CTLSWB has to be set correctly before you can write to SWCHB, and if so I haven't got that part right. But it's the write to SWCHB that sets the button mode.

Bits 4 and 2 of SWCHB control the button mode. 0=2 button mode, 1=1 button mode. I don't recall which bit is which player.

 

Writing a #0 to SWCHB would put it in 2 button mode, and actually that was the default value in Prosystem before I changed it based on some testing.

The system defaults to 1 button mode, as indicated by a test ROM I was using. But with that setup, real 2 button games stopped working. Making SWCHB writable caused those games to start working again. But I overlooked CTLSWB, and that might need to be set correctly before SWCHB is writable on hardware.

 

 

ProSystem is an incredible emulator and it's so easy to set up and use.

 

I installed the update (version d) and the left and right buttons still don't work independently for Xevious. Any hope of getting them sorted out too? Thanks!

I forgot there were issues with Xevious, I'll look at it later. But I suspect it's the difficulty switches, as kenfused mentioned. Unfortunately the difficulty switches don't work the way they should on Prosystem, you have to hold them down to change their position.

[GroovyBee]

Looks like maybe CTLSWB has to be set correctly before you can write to SWCHB, and if so I haven't got that part right. But it's the write to SWCHB that sets the button mode.

On the real RIOT chip if the data direction isn't set correctly then the port bits will never change on the outside of the chip when you write to SWCHB (because they are still inputs). The write to CTLSWB turns them from inputs to outputs. In the real world you'd normally write to the data port first and then set the DDRs to outputs to avoid glitches but hey this is an Atari world.

[gdement]

ProSystem is an incredible emulator and it's so easy to set up and use.

 

I installed the update (version d) and the left and right buttons still don't work independently for Xevious. Any hope of getting them sorted out too? Thanks!

I think maybe with Xevious you have to use the difficulty switches to switch between one and two button mode.

 

I just confirmed this. The buttons work as expected as long as you hold down F5 (left difficulty switch).

Obviously the difficulty switches could be improved. Getting them to stick after you push F5/F6 probably isn't a big deal, but then there's no feedback to let the user know how they're currently set.

[GroovyBee]

Obviously the difficulty switches could be improved. Getting them to stick after you push F5/F6 probably isn't a big deal, but then there's no feedback to let the user know how they're currently set.

I'm no Windows programmer but how about some switch graphics in the window's status pane?