147 replies to this topic

[Curry]

Thanks, guys. Obviously I don't want to put a rock on top of my F5 key, so I ended up changing the difficulty switch setting to Z so that pressing the laser keeps it switched. Finally Xevious is playable!!! I used to be able to play all the way through to the end of the game (and there was really no end, it just puts you back somewhere along the way).

[Derek]

If Zevious ending is just you being bumped back to somewhere, how did anyone decide they had reached the end? When you saw something you recognized? I though there were four of those ships that took up most of the screen and shot the black blobs that erupt and turn silver. Then an ending. How disappointing. All these hours of frustration and I wasn't even close. I never got to the third of these screen hogging ships as your ship moves sooo sllooow compared to all the other stuff out to kill you. Perhaps if one could turn off that annoying background loop, that endless doodly, doodly, doop. Even using all the cheats possible for the NES with the Game Genie, it is still impossible to stay alive.

As for the ProSystem update, up until this weekend, I had ROMs from many years ago, and was unaware that the 7800 had been emulated. It has been great with the games I have tried. I haven't worked up the nerve to try Zevious sitting here at my computer. I am sure it will be just as frustrating as plugging in my 7800 to my TV.

As far as the ProSystem goes, I am awestruck. I am no brain in the computer world, but do like to play 2600, 7800, Coleco, Intellivision games that I do or don't have cartridges for, some are fun, many suck. Either way, you all wrote programs that make this all possible on the computer. Makes my head hurt just trying to fathom how you all did it! Kudos all round! Want a porch built, or your car fixed, come to me. Want to create a cartridge for the 7800 or make an emulator, head for you guys. Guess we all have our areas of expertise.

[Curry]

Don't worry, you'll know when you reach the end of Xevious--they just don't have any big celebration for your achievement, I guess they wanted to let people keep playing to aim for higher scores. Great game, though! If you become familiar with where things are on the ground it gets easier. (Actually, I thought there was a way to turn off the music, but I can't remember.)

[gdement]

I've updated Prosystem again to fix a bug in the last version, which broke Jr Pacman and Winter Games, and probably many other 2 player games. Really dumb error, I should have caught it before posting.

In addition to that bug, I also attempted to implement CTLSWB.
However, before I post that update, I want to make sure I did it correctly because I'm not sure I understand precisely how CTLSWB/SWCHB interact.
Based on the recommended code from the 7800 devkit docs:

LDA  #$14
STA  CTLSWB
LDA  #0
STA  SWCHB

it appears that CTLSWB is used as a mask to control which bits in SWCHB are writable. So in the above example, after setting
CTLSWB= 0001 0100
Then only bits 2 and 4 are writable, while all other bits are read-only and would ignore the data.
Is that correct? CTLSWB is a bit-by-bit setting?
I could probably code something to test this on a console, but that would take a while and I'd like to get the update posted to fix those broken games.
Thanks.

[GroovyBee]

gdement, on Tue Apr 7, 2009 9:55 AM, said:

it appears that CTLSWB is used as a mask to control which bits in SWCHB are writable. So in the above example, after setting
CTLSWB= 0001 0100
Then only bits 2 and 4 are writable, while all other bits are read-only and would ignore the data.
Is that correct? CTLSWB is a bit-by-bit setting?
I could probably code something to test this on a console, but that would take a while and I'd like to get the update posted to fix those broken games.

It doesn't control if they are writable, it controls the data direction of the port. If you set a bit to 1 in CTLSWB it means the corresponding bit in SWCHB is an output, conversely a bit set to 0 mean its an input. In your example writing 0001 0100 to CTLSWB would make bits 2 and 4 outputs and they would be set to their corresponding bit position value in SWCHB. Have a look at page 4 (of 10) in the RIOT datasheet :-

 riot_datasheet.pdf   473K   55 downloads

[gdement]

I'm confused how to interpret the EE stuff into how it behaves from a programming perspective.

RIOT datasheet said:

[...] The voltage on any line programmed to be an output is determined by the corresponding bit in the Port A Data Register (DRA). Data is read directly from the data pins during any read operation. For any output pin, the data transferred into the processor will be the same as that contained in the Data Register if the voltage on the pin is allowed to go to 2.4V for a logic one. Note that for input lines, the processor can write into the corresponding bit of the Data Register. This will not affect the polarity on the pin until the corresponding bit of DDRA is set to a logic one to allow the I/O line to act as an output.

Here's my best guess:

Only if a pin is in "input" mode, then the value of that bit will be writable.
But the written value will not be visible until it is switched to "output" mode. While still in "input" mode, I'm guessing the pin is tristated?
Once switched to output mode, the stored value becomes visible but the bit becomes read-only.

And in groovy chart form:

Input mode													   Output mode
--------------												   ---------------
value is writable												value is read only
pin is tristated,												stored value is readable
readable value dictated by external pulls or
whatever else is driving the line

That's what the datasheet seems to say, but I'm probably still not getting it.

datasheet said:

Note that for input lines, the processor can write into the corresponding bit of the Data Register.

The way that's phrased seems to imply that they're only writable in input mode, not output.

If so, then I don't see how the Atari example code can work:

LDA  #$14
STA  CTLSWB
LDA  #0
STA  SWCHB

Which turns the required bits to outputs before writing to them. Groovybee said earlier this is bad form, but nevertheless they apparently did it this way.
Are all bits *always* writable, regardless of the "direction" they're set to operate?
Does the input/output mode only control whether the stored values are visible, or is writability also affected?


While still in "input" mode, are the pins tristated? In which case their values would be dictated by whatever external +5v/ground sources might be driving those lines in the console?


Sorry, I only took 1 semester of basic intro EE, so I'm having trouble with the translation from EE -> programmer.

[GroovyBee]

This is a rough representation of what the circuit will be for each I/O port pin bonded to the outside world :-



When DDR is high :-

Top transceiver (triangle shape) is enabled.
Bottom transceiver is disabled.
Result: Logic level at point A is transferred to point B.

When DDR is low :-

Top transceiver is disabled.
Bottom transceiver is enabled.
Result: Logic level at point B is transferred to point A.

So nothing is tristated, its either an input or an output. Have a look at an 74LS245 datasheet or a 74LS125 datasheet for the low down on data bus transceiver operation.

I think of DDRs as being "masks". To simulate a fictional port with DATA and DDR registers in "C/C++" code, you'd write something like :-

// Write to port.
unsigned char portDdr=0xAA;
unsigned char portData=0;
unsigned char setPortFollower=portData&portDdr;   // Mask the valid output bits.
WriteToWorld(setPortFollower);					// Write data to the world.

// Read from port.
unsigned char input=ReadFromWorld();		// Get the data from outside.
unsigned char validInputs=input&~portDdr;   // Mask the valid input bits.
validInputs|=setPortFollower;			   // Include the output states.

Hope this helps.

[gdement]

GroovyBee, on Wed Apr 8, 2009 4:23 AM, said:

This is a rough representation of what the circuit will be for each I/O port pin bonded to the outside world :-

Thanks for the detailed post. I do want to get this emulated correctly, but haven't put in the time yet.
I previously had written code to mask off what's writable based on CTLSWB, but it's probably not correct that way so I commented it out. I'll revisit it after I've studied this more.

======

This is a minor bugfix for 1.3d. It adds nothing, just fixes a stupid bug which caused the player 2 button to be permanently held. It was caused by me mixing up hex and decimal numbers.
This fixes the crashes that were happening with Jr Pacman - at least I haven't had that happen since this correction.


 ProSystem_13d2.zip   427.45K   137 downloads
 ProSystem_1_3d2_Src.zip   431.75K   55 downloads

[Trebor]

Awesome! Thanks for the update, gdement.

[BrianC]

Nice update. I noticed what could be a bug with the new version, though.

Spoiler

When I load PacmanPlus's awesome Asteroids Deluxe, the hidden original Asteroids plays instead of Asteroids Deluxe.

[cosmosiss]

Thank you! Glad to see my fav 7800 emu still being updated.

[gdement]

2 button mode wasn't toggled correctly in 1.3d, causing bugs with a few games. This update is based on input from raz0red and groovybee, and quite a bit of experimentation on the console. Controls in all games seem to work properly now.


ProSystem 1.3e
---------------------
Improved emulation of RIOT
- 1/2 button modes are now toggled correctly.
This fixes critical bugs in a few games (Fatal Run, Hat Trick, One on One, Water Ski)
- SWCHA now reflects the interactions of CTLSWA and the RIOT's DRA register. Ditto for SWCHB.
This makes console switches more accurate, but it only affects odd scenarios.
Thanks to raz0red and groovybee for their help figuring these things out





Incidentally, I realized from the schematic that it would be possible to configure RIOT such that the joystick directionals and console switches are locked in the active position. I tried it on the console and succeeded in locking all the directionals at once. This update includes that behavior, however useless it may be.

Raz0red did a lot of research and some disassembly on a few games to help with the 1.3d issues.
He will likely be coming out with a significant update pretty soon. He's found many bugs and been adding functionality on the Wii7800 project. He's porting those improvements back to ProSystem.

[Shannon]

Thanks. Keep up the good work! If your up to it you oughta add HSC support since I believe that Raz0red added that recently.

[BrianC]

Cool! Nice update. Asteroids Deluxe plays now too.

[Mitch]

Hey cool, thanks for the update.

And one more thing for the "to do" list: The difficulty switches are currently emulated as momentary switches instead of toggle switches. This makes some games unplayable.

Mitch

[Trebor]

Thanks for the update.

A problem that is still present is the sound lags a second or two behind when you start from a command line to full screen without the menu bar. The sound can be put back in sync by toggling the menu bar on and off again.

-Trebor

[gdement]

Mitch, on Fri Jun 5, 2009 9:49 AM, said:

And one more thing for the "to do" list: The difficulty switches are currently emulated as momentary switches instead of toggle switches. This makes some games unplayable.

That is something I'd like to change. However, the user will need feedback on the current switch position, and that will require programming some Windows-GUI stuff which I'm not very familiar with. It probably won't be a big deal though.

Quote

A problem that is still present is the sound lags a second or two behind when you start from a command line to full screen without the menu bar. The sound can be put back in sync by toggling the menu bar on and off again.

I know raz0red is improving a lot of things, I'm not sure if this is one of them.

I have severe problems with sound myself - it basically just sounds like static or doesn't work at all. But it works fine on a much faster computer a relative has.
I've noticed that ProSystem uses 100% CPU while running. I'd like to fix the CPU usage, and see if that also ends up helping the sound problem.

[NML32]

gdement, on Fri Jun 5, 2009 1:58 AM, said:

2 button mode wasn't toggled correctly in 1.3d, causing bugs with a few games. This update is based on input from raz0red and groovybee, and quite a bit of experimentation on the console. Controls in all games seem to work properly now.


ProSystem 1.3e
---------------------
Improved emulation of RIOT
- 1/2 button modes are now toggled correctly.
This fixes critical bugs in a few games (Fatal Run, Hat Trick, One on One, Water Ski)
- SWCHA now reflects the interactions of CTLSWA and the RIOT's DRA register. Ditto for SWCHB.
This makes console switches more accurate, but it only affects odd scenarios.
Thanks to raz0red and groovybee for their help figuring these things out

ProSystem_13e.zip

ProSystem_1.3e_Src.zip


Incidentally, I realized from the schematic that it would be possible to configure RIOT such that the joystick directionals and console switches are locked in the active position. I tried it on the console and succeeded in locking all the directionals at once. This update includes that behavior, however useless it may be.

Raz0red did a lot of research and some disassembly on a few games to help with the 1.3d issues.
He will likely be coming out with a significant update pretty soon. He's found many bugs and been adding functionality on the Wii7800 project. He's porting those improvements back to ProSystem.

Fyi
Help About still reports version 1.3d2
at least for me it does.

[gdement]

NML32, on Sat Jun 6, 2009 11:56 AM, said:

Fyi
Help About still reports version 1.3d2
at least for me it does.

damn... I've made that mistake before.
Also a bug just discovered by raz0red which would mess up the controls in-between different games.

Fixed these:
 ProSystem_13e.zip   427.7K   311 downloads

 ProSystem_1.3e_Src__2009_06_06_.zip   571.64K   96 downloads

Edited by gdement, Sat Jun 6, 2009 7:18 PM.

[iratanam]

gdement, on Sat Jun 6, 2009 6:42 PM, said:

NML32, on Sat Jun 6, 2009 11:56 AM, said:

Fyi
Help About still reports version 1.3d2
at least for me it does.

damn... I've made that mistake before.
Also a bug just discovered by raz0red which would mess up the controls in-between different games.

Fixed these:
 ProSystem_13e.zip   427.7K   311 downloads

 ProSystem_1.3e_Src__2009_06_06_.zip   571.64K   96 downloads

Anyone else unable to get this version to work under 64bit Windows 7 Ultimate? It runs but whenever I boot up a rom I get nothing but a black screen. I have tried running it under different compatability modes from XP to Vista and even giving it Admin priv. But still get nothing when I load a rom.

Thanks!

EDIT: Finally got it going when I get the compatability mode to Windows NT go figure. Sorry for the bump this caused

Edited by iratanam, Sat Feb 20, 2010 4:34 PM.

[tremoloman2006]

Nice game!

Sign me up for a copy when its released!

[NightSprinter]

Not sure if I'm doing anything wrong, but the difficulty switch settings didn't seem to work still on Jr. Pac-Man. I still have to hold down F5 or F6 to toggle lives and speedup.

[captainrhythm]

I wish you could configure the emulator to play Robotron with one dual analog controller. Even joy2key doesn't help