Anyone got PETSCII ROBOTS working on a real VIC-20?

[ral-clan]

Hi,

I just bought the 8-bit guy's game "Attack of the PETSCII Robots" and can get it running in VICE, but cannot get it to run on my real VIC-20.
Has anyone else had luck running this game on a real VIC-20?

https://www.the8bitguy.com/product/petscii-robots/

I have used both the Mega-Cart and another, separate RAM expander to test and both behave the same: the game will load to the main menu (with the robot intro picture) and then when START is selected it attempts to load the game map, and either the game crashes to a screen with the READY prompt, or shows the game-play screen and freezes with a constant beep from one of the voices.

I haven't yet tried to swap out the actual VIC-20 computer yet.

I'm wondering if it's a quirk of my setup. I'm loading the game from an uIEC device (.d64) which is normally device 10. There is also a real 1541 attached which is normally device 8. The game will only seem to load from device 8, so I wrote a program which makes the 1541 device 12, and then makes the uIEC device 8. I wonder if some quirk of software switching those device numbers cause the game to fail.

I suppose I could copy the .d64 to the a real floppy on the 1541 then try and load from the 1541 as device 8 and see if that works.

[tokra]

It certainly works on my MegaCart with uIEC set to device #8 and no other device on the bus. Make sure to activate full 35K-RAM expansion (+32K +3K in MegaCart) and maybe run a memory-test program as well.

[groepaz]

no other device on the bus

And remember that means "disconnect the other" not "turn them off"

[Mike]

The requirement for a +35K RAM expansion (i.e. +32K +3K, which Mega-Cart supports out-of-the-box) already been mentioned, a few thoughts:

• If really so, why a requirement for the game to be run off drive #8? It is really no rocket science to support other drive numbers (hint: $BA), and tying new programs to drive #8 - especially when sold commercially - appears to me as some kind of sloppiness.
• If above point is indeed the case, and even reprogramming the drive number per software does not help: that would indicate the software is doing a drive reset (sending UJ over the command channel) at one point. That also resets the changed drive number to the hardware default. Again, unless software has a compelling reason to reset the drive, it should not do it just because. If anything, an I(nitialize) command should be sufficient to ensure the BAM in the drive RAM is valid.
• Finally, why should the software have any issues with more than one drive on the serial bus? Is it employing some kind of drive speeder (which then is likely not to work with SD2IEC drives anyhow, unless it is derived from JiffyDOS)?

ral-clan, please follow-up with a post whether you got the game working (and how!). If any of the points above show relevant for this issue, you should file a bug report to The 8-Bit Guy and point him to here.

Note: I'm not affiliated with this project, and this post is strictly my own opinion.

[orion70]

Looks like a great game, will give it a try. Judging only from the screenshots though, I'd say the C64 and even the PET version are much more polished and eye catching than our beloved one's.

I am also curious if it's a case of static drive number, a memory issue or whatever.

[tokra]

I tried this a little bit today, what I found out is:

- the game NEEDS to be loaded from drive #8. It seems hardcoded to load the other parts from that device number.
- I connected a second drive with #8, having the original uIEC set to #9. I then switched the original drive to #10 and the uIEC to #8 by software "U0>"+CHR$(8) and this way loading still worked fine
- I noticed though that the integrated SJLOAD in the MegaCart sometimes did not like the device-number changes. So if you do it that way only activate SJLOAD manually with SYS 40000 after all device-numbers have been switched around. The game still works with SJLOAD then and loads the parts quickly. So it seems to use kernal-routines for loading.

End-result: Set the device to load from to #8 from power-on and you should be fine. Also make sure to enable full 35K, this is most likely the cause for the crash.

[Mike]

[...]

Also make sure to enable full 35K, this is most likely the cause for the crash.

... and, while doing so, please use a known working combination of one of your VIC-20s and RAM expansions capable of providing +35K!

You posted about issues with that particular configuration already in 2018, see here: RAM expansion cross-talk issues, and it's hopefully sufficient background we elaborated in that thread.

[ral-clan]

I tried this a little bit today, what I found out is:

- the game NEEDS to be loaded from drive #8. It seems hardcoded to load the other parts from that device number.
- I connected a second drive with #8, having the original uIEC set to #9. I then switched the original drive to #10 and the uIEC to #8 by software "U0>"+CHR$(8) and this way loading still worked fine
- I noticed though that the integrated SJLOAD in the MegaCart sometimes did not like the device-number changes. So if you do it that way only activate SJLOAD manually with SYS 40000 after all device-numbers have been switched around. The game still works with SJLOAD then and loads the parts quickly. So it seems to use kernal-routines for loading.

End-result: Set the device to load from to #8 from power-on and you should be fine. Also make sure to enable full 35K, this is most likely the cause for the crash.

I pretty much do this. I switch my real 1541 to drive 12 in software, then make the iUEC (which is normally drive 10) become drive 8.

Still experience the problems.

I don't use SJLOAD from the Mega-Cart (I'm not sure what that is).

[ral-clan]

[...]

Also make sure to enable full 35K, this is most likely the cause for the crash.

... and, while doing so, please use a known working combination of one of your VIC-20s and RAM expansions capable of providing +35K!

You posted about issues with that particular configuration already in 2018, see here: RAM expansion cross-talk issues, and it's hopefully sufficient background we elaborated in that thread.

Yes, I had wondered if that might be the problem (the same as I experienced with the Zork game). However, in that case I was able to get the Zork game to work by using different 35K RAM expander (removing the Mega-Cart from the setup). In the case of PETSCII robots, I tried using that second RAM expander (a clone of VICMEM by Retro Innovations), but got exactly the same issues in PETSCII robots as described in the original post.

[Mike]

Yes, I had wondered if that might be the problem (the same as I experienced with the Zork game). However, in that case I was able to get the Zork game to work by using different 35K RAM expander (removing the Mega-Cart from the setup). In the case of PETSCII robots, I tried using that second RAM expander (a clone of VICMEM by Retro Innovations), but got exactly the same issues in PETSCII robots as described in the original post.

O.K. - that then only leaves one particular, and rather nasty source of the problem: use of uninitialized RAM.

On your freshly powered on VIC-20, before loading the game, please enter these 5 lines in direct mode:

Code: Select all

FORT=673TO767:POKET,.:NEXT
FORT=828TO1023:POKET,.:NEXT
FORT=1024TO4095:POKET,.:NEXT
FORT=40960TO49151:POKET,.:NEXT
FORT=4618TO32767:POKET,.:NEXT

These 5 lines take some time to execute and clear all BASIC RAM (except a save spot for the variable T) and two small buffers in the OS workspace to all bits zero. Then load the game and look what happens now.

In any case, you should consult the result with the manufactorer of the game. This is probably all that can be helped out by remote diagnosis.

[tokra]

O.K. - that then only leaves one particular, and rather nasty source of the problem: use of uninitialized RAM.

I would think this to be highly unlikely. It looks more to me like an issue with the particular VIC-20 machine, maybe some lines on the cartridge port are not working and as such the machine does not see the full 35K.

You really! should do a full RAM-check and post the results here, you can find Mike's excellent RAM_CHECK-program here:

viewtopic.php?f=11&t=9090&start=30

It also checks for crosstalk between different memory blocks, this might be a problem as well.

[Mike]

I would think this to be highly unlikely. [...]

I thought ral-clan had already done the necessary 'homework' in the wake of the earlier RAM issues he had, but in case he did not, no harm done in pointing him to my RAM test, indeed.