BlackBox9 cartridge emulation. [More information needed.]

[radius75]

Related to #314

I checked running bb9 on U2+ 3.10f
Function "2 - MUSICAL INSTRUMENT" (music keyboard), Selected on the start screen.
It is displayed with moving noises on the screen.
Is there any way to fix this by changing the settings in Ultimate options?
The same CRT in Vice3.7.1 works without such glitches.

[radius75]

Upload Video:
https://user-images.githubusercontent.com/1929111/234553013-d4eb8eef-ceea-4ad5-bab8-488a3ccd4b3f.mp4

[GideonZ]

It is probably a bug in the emulation. But I don't know the BB9 well enough to understand where these glitches are coming from. I saw them also in the menu. I quickly drafted the BB9 emulation within 15 minutes, so it may need some verification / debugging.

[radius75]

I understand.
I also noticed that the freeze button is active (causes bb9 crash)
This cartridge only has a Reset Button.

[GideonZ]

I fixed the freeze button issue. The same issue causes problems in the U64 when switching cartridges.

[radius75]

It's a commit from Vice mirror repo.
BB9 support seems to have appeared somewhere between 3.6.0 and 3.6.1
I don't know if it can help in this case.
VICE-Team/svn-mirror@a1c88de

[radius75]

I found Vice 3.6.1 and crt bb9 runs there without glitches.
But I think the commit I found is not necessarily correct. There is already version 3.7.1 and a lot may have been changed/improved during this time.

[GideonZ]

Comparing a hardware implementation and a software implementation might put us on the wrong track. It might help to check if the basic logic is correct; but that actually already seems to be the case, as the software inside of the cart runs just fine. You see, the glitches are very short in nature. One byte of graphics crap, sometimes a bit more. It seems to fail when the CPU writes and the VIC reads. The real question is: why does this happen with BB9 and not with other carts, e.g. Jupiterlander? This behavior was observed with Jupiterlander, but this was timing related. Which cartridge runs is independent of the timing; or in other words: the timing is set for the ultimate as a whole, not for a specific cart. It would help to understand what BB9 is doing with the VIC. Does it use Ultimax mode a lot?

…

On Thu, Apr 27, 2023 at 5:16 AM radius75 ***@***.***> wrote: It's a commit from Vice's mirror repo. BB9 support seems to have appeared somewhere between 3.6.0 and 3.6.1 I don't know if it can help in this case. ***@***.*** <VICE-Team/svn-mirror@a1c88de> — Reply to this email directly, view it on GitHub <#334 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUFDSMXDOBGC4V6WIRIVCTXDHQKXANCNFSM6AAAAAAXMH5HJM> . You are receiving this because you commented.Message ID: ***@***.***>

[radius75]

BB9 is different from the rest of BB3,4,8.
It had a copy protection chip. The launcher verified that the "encrypted key" was correct in this system and allowed it to boot. Otherwise it crashed the computer.
Really little is known about this device because for a long time no one copied it, no clones were made.
Only from the modder version of Vice 3.1 it was possible to run it.
And since 3.6.1 it has been officially added.
I found a video on YT where these glitches occur. I suspect it's Vice 3.1.
https://www.youtube.com/watch?v=Kfh4mGIUxjM&t=1s
I'm trying to contact the author of this video right now to confirm if it's a Vice emulation or a real Commodore.

[radius75]

The author of the video confirmed to me on FB, that this video was made with BB9.crt on modded Vice3.1

[GideonZ]

Ok.. without further info, and only links to Vice, a software emulator, I think it's best to remove it and drop the support for BB9. Message ID: ***@***.***>

…

[radius75]

It must be so. More information may be available from people who added BB9 to Vice, or those who somehow managed to dump to a BIN file. Maybe someday.. If I manage to find out more, I will definitely post it here. Anyway, thank you very much for your effort.

[mrdudz]

The hardware equivalent of doing what VICE does would be gating game/exrom with phi2, so the cartridge is only active in CPU cycles.

To check whether that is true, you could change line 131 in blackbox9.c

https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/c64/cart/blackbox9.c#l131

to

cart_config_changed_slotmain((currbank << CMODE_BANK_SHIFT) | currmode, (currbank << CMODE_BANK_SHIFT) | currmode, CMODE_WRITE);

if you now get the same glitches in VICE; then this is the problem.

That said, the whole implementation is based on guesswork and i don't know how the actual hardware works exactly - i wouldnt be surprised to see those glitches also with a real cartridge. You might want to contact someone who owns the physical cartridge first.

[GideonZ]

The hardware equivalent of doing what VICE does would be gating game/exrom with phi2, so the cartridge is only active in CPU cycles.

Interesting... I am not sure if I have PHI2 available in that module, but I could route it there. I am trying to get my head around how this could cause the glitches. It seems to be related to the write from the CPU.

To check whether that is true, you could change line 131 in blackbox9.c https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/c64/cart/blackbox9.c#l131 to cart_config_changed_slotmain((currbank << CMODE_BANK_SHIFT) | currmode, (currbank << CMODE_BANK_SHIFT) | currmode, CMODE_WRITE); if you now get the same glitches in VICE; then this is the problem.

Thanks.. I have never looked into the VICE source code, nor tried to build VICE myself... so I might choose another route to find out what goes wrong. Best regards, Gideon Message ID: ***@***.***>

…

[mrdudz]

Just gave it a quick try - i dont see any glitches even with that change

I am not sure if I have PHI2 available in that module, but I could route it there. I am trying to get my head around how this could cause the glitches.

When Ultimax is active in VICII cycles, then VICII sees cartridge ROM and will display garbage most likely (eg you can also see this with Action Replay V5, eg for a short time before it starts loading).

Why it would cause such "sparkles" as the OP describes is a good question though - it would have to switch between ultimax and non ultimax a lot. The ROM i have here doesnt do this though :)

[GideonZ]

I agree with you completely. IMHO, the sparkles are too short for switching back and forth. Message ID: ***@***.***>

…

[mrdudz]

I think i know what happens... first of all, the cartridge does not use a register, but it switches the mode depending on the address in the IO1 range (and apparently both on read and write). That actually explains how it can produce "sparkles" that are one cycle (aka 8 pixels) wide:

The cartridge has trampoline code in the IO1 area. When the code jumps to such trampoline, it will run the code in IO1, and at the same time switch the cartridge mode every cycle. I have put breaks on the entire IO1 range in VICE, so you can see this:

Sync reset
R 01 01
R 01 00
R 01 01
Sync reset
R 01 02
R 01 03
R 01 02
Sync reset
R 01 01
R 01 00
R 01 01
Sync reset
R 01 02
R 01 03
R 01 02
Sync reset
R 01 01
R 01 00
R 01 01
R 01 02
R 01 03
R 01 02
Sync reset
R 01 01
R 01 00
R 01 01

etc (every "Sync reset" marks when a breakpoint hits, ie when it jumped into IO1). The second value is game/exrom - so that changes rapidly all the time.

and to confirm the theory, this patch produces the glitches in VICE too:

--- src/c64/cart/blackbox9.c    (Revision 43715)
+++ src/c64/cart/blackbox9.c    (Arbeitskopie)
@@ -119,7 +119,7 @@
     currbank = (addr >> 7) & 1;
     currmode = ((addr >> 5) & 2) | ((addr & 1) ^ 1);
 
-    cart_config_changed_slotmain(CMODE_RAM, (currbank << CMODE_BANK_SHIFT) | currmode, CMODE_READ);
+    cart_config_changed_slotmain((currbank << CMODE_BANK_SHIFT) | currmode, (currbank << CMODE_BANK_SHIFT) | currmode, CMODE_READ);
     return roml_banks[0x1e00 + (roml_bank << 13) + (addr & 0xff)];
 }
 
@@ -128,7 +128,7 @@
     currbank = ((addr >> 7) & 1) ^ 1;
     currmode = ((addr >> 5) & 2) | ((addr & 1) ^ 1);
 
-    cart_config_changed_slotmain(CMODE_RAM, (currbank << CMODE_BANK_SHIFT) | currmode, CMODE_WRITE);
+    cart_config_changed_slotmain((currbank << CMODE_BANK_SHIFT) | currmode, (currbank << CMODE_BANK_SHIFT) | currmode, CMODE_WRITE);
 }
 
 static int blackbox9_dump(void)

I didnt see them before, because i only patched "write". it is the reads that are the problem!

So, the solution is still the same: game/exrom must be inactive at all times in VICII cycles :) (This btw is the case for other cartridges too - eg Retro Replay)

[radius75]

That said, the whole implementation is based on guesswork and i don't know how the actual hardware works exactly - i wouldnt be surprised to see those glitches also with a real cartridge. You might want to contact someone who owns the physical cartridge first.

Unfortunately, I don't have access to the real BB9. I found a video from YT where real hardware is presented.The graphic glitches are not visible.
https://youtu.be/u90PdcQuJH0

[GideonZ]

So, the solution is still the same: game/exrom must be inactive at all times in VICII cycles :) (This btw is the case for other cartridges too - eg Retro Replay)

That kind of sucks. :) This is totally incompatible with how the U64 does it. Since the introduction of the 48 MHz turbo mode, the decode needs to be known at every clock cycle. This is necessary to know when (if) to make an external cycle on the cartridge port or not. To get some external carts to work, there is a dynamic mode which slows down the bridge whenever a mode change is expected, but this won't work for internal carts. Anyway, that's something I need to think a bit more about later, we are now discussing the U2 cartridge. So, the solution is still the same: game/exrom must be inactive at all

times in VICII cycles :) (This btw is the case for other cartridges too - eg Retro Replay)

It doesn't apply to all carts. Ultimax carts certainly do need to do a read during a VIC cycle, and all carts that are supposed to work at 2 MHz in a C128 also do. Thank you for your contribution.. I will certainly try to gate the EXROM/GAME outputs with PHI2.

…

Message ID: ***@***.***>

[mrdudz]

It doesn't apply to all carts. Ultimax carts certainly do need to do a read during a VIC cycle, and all carts that are supposed to work at 2 MHz in a C128 also do.

Did some grepping in the VICE source, its at least these carts that use a different config in VIC and CPU cycle (not necessarily "inactive" in the VICII cycle!):

Gmod2, stardos, blackbox9, magic formel, mmc replay, freeze machine, partner64, atomic power, isepic, freeze frame 2, freeze frame, rrnet-mk3, capture, formel64, LTKernal, IEEE FLash 64, Final Cartridge 3, Final Cartridge Plus, IDE64, MMC64, EXOS, Comal80, Expert Cartridge, Retro Replay

Mind you, that even very simple ROM cartridges (which do not "need" this) sometimes gate game/exrom with phi2, so the above list is probably not complete. I'd expect that at least all that somehow use the address on the bus (instead of the data) have to do it.

I will certainly try to gate the EXROM/GAME outputs with PHI2.

As said above, this should not be generally the case - some cartridges need it. Some cartridges will even use different modes in both cycles, so this should be a per cartridge thing.

[radius75]

I checked fw3.10i on U2+. The BB9 CRT works very well.
Thank you both for your commitment. Thread can be closed.

[radius75]

A working "replica" of BB9 has been created
The behavior of the GAL chip has been rewritten there so that the cartridge behaves in accordance with the original one (whose original programming is unknown).

I will quote and try to translate the explanation of the author of this new bb9 regarding the screen glitches in music keyboard mode.

https://www.c64scene.pl/viewtopic.php?p=49620#p49620

First, I will describe where these disturbances come from.
The organ program uses this command extensively
Code:
DECD jmp ($0115)
This is a 3-byte command. When executing it, the processor reads the addresses DECD, DECE, DECF bit 0 of the address each time goes to the control register of the GAME line. It sets the GAME lines to 1, 0, 1 in subsequent cycles, i.e. reading byte 2 turns on the Ultimate mode for a moment, then reading byte 3 turns it off again.
But if, while executing this instruction, the 6502 reads the second byte to enable Ultimat mode, and the VIC starts displaying the BAD line, then for the entire BAD line the VIC-II loses access to RAM, hence the glitch.
The trick is for the GAL to detect this situation and block the update of the GAME registry in the second cycle.

[mrdudz]

ah much better idea would be to gate game/exrom with phi2 and not let the vicii see ultimax mode :)

[radius75]

In bb9, the phi2 line was never connected, looking at the pcb photos and available schematics.
The author of the replica suspects that ultimax could have been used, for example, for programs written for ultimax mode.
Using the phi2 line will limit the EPROM to 128KB, and tested that it can now be up to 256KB.
Everything is in testing phase.😉

--
The replica also fixed the title screen without using phi2. There are no graphic glitches.

[radius75]

The author of replica pointed out one more serious error in bb9 emulation on Vice and Ultimate.
The <-q command (and a reset with one of the keys pressed) should disconnect the eprom completely. And then return to bb9 only by reset button. Tested on original bb9.

on a real bb9, after executing <-q, peek(56880) returns a numeric value.
Doing this in emulation causes a crash.

This is important when running programs. The standard F3 key runs <-Q:RUN:
Which guarantees correct work of the loaded program.

A Reset with the Spacebar pressed should unlink the eprom and go to Basic2.0

If I get more details on this, I'll make a Reopen Issue

[mrdudz]

Using the phi2 line will limit the EPROM to 128KB

that makes no sense

[radius75]

Using the phi2 line will limit the EPROM to 128KB

that makes no sense

it will supposedly take an extra Input in the GAL

Perhaps he means the lines needed to address the memory.

Ambitious, maybe soon it will be bb10 ;D
🫣

[radius75]

I'm reopening this Issue.
The author of the bb9 replica pointed out a significant bug in the bb9 emulation in Vice, the same bug is in Ultimate.

The original bb9 disconnected the eprom completely after executing the <-q command.
Performing a Reset while holding down the Space key also disconnected the Eprom.
Return to bb9 only possible by Reset.

The author of replica pointed out one more serious error in bb9 emulation on Vice and Ultimate. The <-q command (and a reset with one of the keys pressed) should disconnect the eprom completely. And then return to bb9 only by reset button. Tested on original bb9.

on a real bb9, after executing <-q, peek(56880) returns a numeric value. Doing this in emulation causes a crash.

This is important when running programs. The standard F3 key runs <-Q:RUN: Which guarantees correct work of the loaded program.

A Reset with the Spacebar pressed should unlink the eprom and go to Basic2.0

If I get more details on this, I'll make a Reopen Issue

[mrdudz]

I think what is missing is a simple "disable cartridge" feature, very similar to how it works in AR.

The condition is apparently "when IO1 is written, bit 7 of addr is 0, bit 6 and bit 0 of addr are 1" (ie 0xde41). In that case just "disconnect" the register from IO1 (but still update the bank/game/exrom) until reset.

[radius75]

I think what is missing is a simple "disable cartridge" feature, very similar to how it works in AR.

The condition is apparently "when IO1 is written, bit 7 of addr is 0, bit 6 and bit 0 of addr are 1" (ie 0xde41). In that case just "disconnect" the register from IO1 (but still update the bank/game/exrom) until reset.

For me, it worked as I imagined. (Vice latest fixed build)
And with the contents of the manual.
Even reset+Control runs the "Synthimat 64" program, loaded and run previously on the C64.
Thank you.
All that remains is to wait for Gideon to find some precious time :)