VBXE - Can't switch boot core (VBXE IO error)

[AA_ron]

I tried to get a demo to work, by trying old cores, booted from the v2fx124a_vga.xbf core (dated 2010)... and now I'm stuck.

I REALLY shouldn't have tried that.

 

This is an Atari 800XL with VBXE and custom VGA port, and U1MB (FJC firmware). Using FujiNet to mount .atr files, and SpartaDOS X from U1MB.

It was working fine for months, so install should be fine. I could easily change cores between the "current" versions (dated 2013).

 

Then...

I used the old FC.COM to install the old vga core in a higher slot number, marked it bootable, rebooted, and my VBXE video is now split/corrupted.

I'm now using composite video out for a non-corrupted display.

The initial slots still have the original cores, so I need to switch the boot core to "2" for example.

 

FC.COM is erroring: VBXE IO error

DCFG.COM is erroring: VBXE IO error

    Documentation seems to say DCFG.COM bypasses VBXE IO and goes straight to FPGA (oh well).

    I found this DCFG.COM in an old copy of release-cores.zip (dated 2009)

The U1MB bios now has the VBXE option grayed out, so not detected?!

 

What else might I try to switch boot core?

(I & friends are reasonable with electronics, and could setup a USB serial connection if needed)

 

Now I've got a double screen view and unreadable text.

 

When I run FC.COM from the newest release (from 2013)

(This is me reverting to composite video output)

 

FC.COM fails "VBXE IO error".

And when I run DCFG.COM it gives same error (even if I switch the current drive).

 

These were the old core and FC.COM I was idiotically messing with:

[Beeblebrox]

@AA_ron which u1mb firmware version are you running, the latest 4.2 from jan 2023?

 

Have you tried re flashing the u1mb firmware? 

Tbh not that I think it'll make a difference if it was all working before, but just checking. 

 

Edited March 23 by Beeblebrox

[woj]

Did you try the VBXE flashing tools from newer core releases? There is one floating around here, not to be found on Lotharek's site, with the NTSC color palettes.

[flashjazzcat]

I found the FC.COM from the core pack with the Rocky palettes posted by Tebe not to work well on one 800XL, leading me to suspect a VBXE fault. But then I tried using FC from the core pack on Lotharek's site and was able to flash the Rocky palettes without problems.

 

U1MB firmware certainly lacks the ability to give you split-screen RGB video, anyway, and the VBXE setting is greyed out because ithe plugin is no longer recognising the VBXE hardware.

Edited March 23 by flashjazzcat

[electron]

5 hours ago, flashjazzcat said:

I found the FC.COM from the core pack with the Rocky palettes posted by Tebe not to work well on one 800XL, leading me to suspect a VBXE fault. But then I tried using FC from the core pack on Lotharek's site and was able to flash the Rocky palettes without problems.

 

U1MB firmware certainly lacks the ability to give you split-screen RGB video, anyway, and the VBXE setting is greyed out because ithe plugin is no longer recognising the VBXE hardware.

This is my fault - FC.COM included there was a "debug version" or "happy compilation" (not very functional) by mistake. And is circulating around since then. The most current package is this:

vbxe_package_20230910.zip

[AA_ron]

5 hours ago, flashjazzcat said:

I found the FC.COM from the core pack with the Rocky palettes posted by Tebe not to work well on one 800XL, leading me to suspect a VBXE fault. But then I tried using FC from the core pack on Lotharek's site and was able to flash the Rocky palettes without problems.

 

U1MB firmware certainly lacks the ability to give you split-screen RGB video, anyway, and the VBXE setting is greyed out because ithe plugin is no longer recognising the VBXE hardware.

It was late when I goofed this, so I just now verified and re-tried.

 

cores126 version of FC.COM: VBXE IO error

cores124 version of FC.COM: VBXE IO error

 

I found cores126 as "last" (its also Release CORES) on https://lotharek.pl/productdetail.php?id=53
I found cores124 on http://ftp.pigwa.net/stuff/projects/VideoBoard XE/old/

 

I found @tebe's VBXE cores pack, and it DOES have a different FC.COM, which runs.

(NOTE: The DCFG.COM in Tebe's, says VBXE IO error)

FC.COM shows that I only have 4 slots, and they are all empty.

In reality I should actually have 12 slots, and preloaded with: 1) V2 126 FX, 2) V2 126 FX Rambo, 3) V2 126 GTIA, 4) V2 126 GTIA Rambo

Oh, and I tried merely setting BootBank to #1, but it thinks it's empty, so didn't let me.

 

Are there any other suggestions, or should I take the risk and try flashing core #4, and BootBank it?

It feels like this could corrupt more. 😐 

Are there OTHER packages floating around?
 

Tebe's package

I don't think the standard FC.COM said "happy compilation" (but both report v1.17)

 

[AA_ron]

32 minutes ago, electron said:

This is my fault - FC.COM included there was a "debug version" or "happy compilation" (not very functional) by mistake. And is circulating around since then. The most current package is this:

vbxe_package_20230910.zip 6.31 MB · 1 download

Thanks for finding/posting this.

 

When merely starting FC.COM and DCFG.COM, each says "VBXE IO error" 😞 

[electron]

6 minutes ago, AA_ron said:

Thanks for finding/posting this.

 

When merely starting FC.COM and DCFG.COM, each says "VBXE IO error" 😞 

Do you mean - FC/DCFG from package above still fails or that one from Tebe's post?

[flashjazzcat]

20 minutes ago, AA_ron said:

FC.COM shows that I only have 4 slots, and they are all empty.

Precisely the same thing I was experiencing with FC from Tebe's post in the NTSC palette thread.

[AA_ron]

8 hours ago, Beeblebrox said:

@AA_ron which u1mb firmware version are you running, the latest 4.2 from jan 2023?

 

Have you tried re flashing the u1mb firmware? 

Tbh not that I think it'll make a difference if it was all working before, but just checking. 

 

Yup, v4.20.

 

WHOA, HEY!!, WHAT?!?!... Let me try to retrace my steps...

 

1) I put 20230910 atr on D1

2) I enabled SpartaDOSX in U1MB

3) I ran FC.COM, which said "VBXE IO error"

4) I ran DCFG.COM, which said "VBXE IO error"

5) I hit Help-Reset, verified the U1MB version v4.20

6) ... but also noticed VBXE was NOT grayed and set to disabled!!?!?

7) I set VBXE properly, exited BIOS (which didn't reboot)

 Ran FC.COM (20230910 version, because it was there)

9) Set BootBank to #1

10) Power cycled, and everything works!!

 

I know that VBXE setting was gray before, and I'm not sure what re-enabled the choice.

Could be related to going into BIOS warm from SDX (not cold boot)?

 

Strange.

Thanks everyone!!

[flashjazzcat]

11 minutes ago, AA_ron said:

I know that VBXE setting was gray before, and I'm not sure what re-enabled the choice.

Could be related to going into BIOS warm from SDX (not cold boot)?

The plugin relies on VBXE's $D6/7xx pin being connected to the VB pin on the U1MB. The signal can be 'disabled' (so, VBXE core off), $D6xx, or $D7xx. The plugin looks for the VBXE core signature on pages $D6 and $D7; if it finds VBXE at either address, it then attempts to disable the core (and then re-enable it) and if it can't, the VBXE page setting is greyed out. Likewise, if no VBXE info is found at all, the setting will be greyed out. Perhaps VBXE was somehow set to 'disabled' in the first place, and this is why FC.COM could locate the hardware at neither address. The test is carried out on every reset, warm or cold.

Edited March 23 by flashjazzcat

[electron]

15 minutes ago, flashjazzcat said:

Precisely the same thing I was experiencing with FC from Tebe's post in the NTSC palette thread.

Forget about "happy compilation" FC.COM - throw it away, delete it.

The most recent version is 1.17 from package dated 20230910 and it should work for both D6xx and D7xx installations.

[electron]

1 hour ago, AA_ron said:

Yup, v4.20.

 

WHOA, HEY!!, WHAT?!?!... Let me try to retrace my steps...

 

1) I put 20230910 atr on D1

2) I enabled SpartaDOSX in U1MB

3) I ran FC.COM, which said "VBXE IO error"

4) I ran DCFG.COM, which said "VBXE IO error"

5) I hit Help-Reset, verified the U1MB version v4.20

6) ... but also noticed VBXE was NOT grayed and set to disabled!!?!?

7) I set VBXE properly, exited BIOS (which didn't reboot)

 Ran FC.COM (20230910 version, because it was there)

9) Set BootBank to #1

10) Power cycled, and everything works!!

 

I know that VBXE setting was gray before, and I'm not sure what re-enabled the choice.

Could be related to going into BIOS warm from SDX (not cold boot)?

 

Strange.

Thanks everyone!!

For me it seems that U1MB in your machine is a master of your VBXE  As @flashjazzcat pointed out... This core based detection should be only optional in my opinion. Maybe VBXE presence: ON/OFF/Automatic (core based) and separately VBXE base: D6/D7 for presence ON/Automatic.

Edited March 23 by electron

[AA_ron]

1 hour ago, flashjazzcat said:

The plugin relies on VBXE's $D6/7xx pin being connected to the VB pin on the U1MB. The signal can be 'disabled' (so, VBXE core off), $D6xx, or $D7xx. The plugin looks for the VBXE core signature on pages $D6 and $D7; if it finds VBXE at either address, it then attempts to disable the core (and then re-enable it) and if it can't, the VBXE page setting is greyed out. Likewise, if no VBXE info is found at all, the setting will be greyed out. Perhaps VBXE was somehow set to 'disabled' in the first place, and this is why FC.COM could locate the hardware at neither address. The test is carried out on every reset, warm or cold.

When I saw the grayed(greyed) out VBXE, my heart sank.

Then I tried lots of things... and you're right, it's possible that at some point between heart-sink and this morning, it became available again, and set itself to disabled.

Not sure when it was became set to disabled, I documented the final steps I remembered... knowing they may be unrelated. Heh.

 

For posterity, it's good to have the best documented resolution steps possible.

And the final caveat we're providing, is to keep checking the VBXE setting in U1MB Bios. 🙂 

 

@flashjazzcat, in December I developed the interest to reacquire my original Atari computers, and upgrade them as well. Your YouTube videos and contributions have been a delight to watch and purchase. They've been a big help & enabler. Thank you.

[flashjazzcat]

1 hour ago, electron said:

This core based detection should be only optional in my opinion. Maybe VBXE presence: ON/OFF/Automatic (core based) and separately VBXE base: D6/D7 for presence ON/Automatic.

Why? I am yet to see it fail on a machine not blighted by stability issues or other problems. The entire point of making the hardware settings dependent on the presence of the actual hardware and the availability of software control was to avoid the situation so often encountered with the original U1MB firmware, such as the user believing (for example) that he had enabled stereo POKEY when stereo POKEY wasn't working or was disconnected from M0 pin, or that he had changed the VBXE base address when the $D6/7 line was hard-wired to $D6 instead of the VB pin on the U1MB.

 

Even a configuration reset on the U1MB will result in the VBXE base address dafaulting to $D6. As said: the only reason the base address setting will be greyed out is if something happened or was done which resulted in the VBXE core being undetectable, and that's something the user should know about and react to accordingly.

Edited March 23 by flashjazzcat

[electron]

34 minutes ago, flashjazzcat said:

Why? I am yet to see it fail on a machine not blighted by stability issues or other problems. The entire point of making the hardware settings dependent on the presence of the actual hardware and the availability of software control was to avoid the situation so often encountered with the original U1MB firmware, such as the user believing (for example) that he had enabled stereo POKEY when stereo POKEY wasn't working or was disconnected from M0 pin, or that he had changed the VBXE base address when the $D6/7 line was hard-wired to $D6 instead of the VB pin on the U1MB.

 

Even a configuration reset on the U1MB will result in the VBXE base address dafaulting to $D6. As said: the only reason the base address setting will be greyed out is if something happened or was done which resulted in the VBXE core being undetectable, and that's something the user should know about and react to accordingly.

Are you sure that old VGA core (the cause of a problem here) is detectable by U1MB? In fact cores and VBXE FPGA interface hardware are completely independent from each other...

Edited March 23 by electron

[flashjazzcat]

11 minutes ago, electron said:

Are you sure that old VGA core (the casue of a problem here) is detectable by U1MB? In fact cores and VBXE FPGA interface hardware are completely independent from each other...

Not sure at all, but if one is using a deprecated core and there's no way around it, one can remove the plugin entirely or write one which works the way you want it to. Do you have details of how the VGA core metadata deviates from the GTIA and FX cores? The software supports what's described in the VBXE core manual.

 

This is the only thing mandatory for a positive is $10 (FX) or $11 (GTIA) in the version register:

	ldy #VBXE_CR_VERSION
	lda (Temp1),y
	cmp #$10
	beq Found
	cmp #$11
	beq Found

Anythat that satisfies this will result in the $D6/7 setting being accessible.

Edited March 23 by flashjazzcat

[electron]

1 minute ago, flashjazzcat said:

Not sure at all, but if one is using a deprecated core and there's no way around it, one can remove the plugin entirely or write one which works the way you want it to. Do you have details of how the VGA core metadata deviates from the GTIA and FX cores? The software supports what's described in the VBXE core manual.

You're right, but my proposal was to implement solution which frees U1MB from this burden. Of course this is up to you  To be honest I don't remember details about this old core nor see any sense in implementing its recognition.

[flashjazzcat]

1 minute ago, electron said:

You're right, but my proposal was to implement solution which frees U1MB from this burden. Of course this is up to you

It's hardly burdensome; the code is slight and plugin-based, and if the handful of people with special requirements want an alternative plugin which works in the way you describe (rather than burdening the average user with yet more settings they don't need), I'll happily provide it.

3 minutes ago, electron said:

 To be honest I don't remember details about this old core nor see any sense in implementing its recognition.

You've piqued my curiosity now, so I'll flash it myself and study the signature region.

[electron]

6 minutes ago, flashjazzcat said:

It's hardly burdensome; the code is slight and plugin-based, and if the handful of people with special requirements want an alternative plugin which works in the way you describe (rather than burdening the average user with yet more settings they don't need), I'll happily provide it.

You've piqued my curiosity now, so I'll flash it myself and study the signature region.

You can't automatically detect and forsee everything. Reality always wins easily. Do not even try  Better have a few "jumpers" just in case.

[flashjazzcat]

14 minutes ago, electron said:

You can't automatically detect and forsee everything. Reality always wins easily. Do not even try  Better have a few "jumpers" just in case.

I think you're right. I just flashed the VGA core (admittedly on a Rapidus-equipped machine which has almost driven me to to a nervous breakdown already) and signature information makes a ghostly and barely readable attempt at appearing in $D6, judging by EYE2 (things are jumping around all over the place). This indeed confuses the VBXE plugin since it intermittently manages to read the unstable bytes, and sometimes doesn't.

 

I'll have a look at this when I get time. The chief thing here is to cater for corner cases without complicating matters for the 99 per cent of users for whom things work fine as is (and for whom the presence of an additional setting could cause as many misunderstandings as problems it solves).

 

Edited March 23 by flashjazzcat

[flashjazzcat]

An if determinacy is a positive in any way, I was just able to replicate the exact same scenario experienced by the OP during my experiments (I assume the split screen effect is a result of running the VGA core without the proper crystal installed).

[electron]

8 minutes ago, flashjazzcat said:

I think you're right. I just flashed the VGA core (admittedly on a Rapidus-equipped machine which has almost driven me to to a nervous breakdown already) and signature information makes a ghostly and barely readable attempt at appearing in $D6, judging by EYE2 (things are jumping around all over the place). This indeed confuses the VBXE plugin since it intermittently manages to read the unstable bytes, and sometimes doesn't.

 

I'll have a look at this when I get time. The chief thing here is to cater for corner cases without complicating matters for the 99 per cent of users for whom things work fine as is (and for whom the presence of an additional setting could cause as many misunderstandings as problems it solves).

 

I really don't remember. I'm not even sure if something has degraded in the newer cores - something stinks here. The plan is to refactor FX/GTIA from scratch - GTIA first, focusing on emulation quality. But there are waves of retro hardware coming - not only Atari - I have MSX and ZX to build and so on... If anyone is still interested in new VBXE cores, tell me about it from time to time - just for motivation

[electron]

9 minutes ago, flashjazzcat said:

An if determinacy is a positive in any way, I was just able to replicate the exact same scenario experienced by the OP during my experiments (I assume the split screen effect is a result of running the VGA core without the proper crystal installed).

Yeah, 28 MHz crystal needed. Readout "instability" is probably also result of this.

[flashjazzcat]

6 minutes ago, electron said:

If anyone is still interested in new VBXE cores, tell me about it from time to time - just for motivation

Yep - that works here too.

4 minutes ago, electron said:

28 MHz crystal needed. Readout "instability" is probably also result of this.

I ran the VGA core very successfully on an Incognito 800 a year or two back (there's a video), but I wasn't sure that register instability would be problematic without the 28MHz crystal. Thanks - that explains a lot, and makes this even more of a corner case.  I suspect, then, that if the OP's machine (and mine) had the right crystal, the U1MB plugin would have ID'd the FX core and all would have been well.

 

PS: I was getting early PMG DMA in the U1MB setup menu and other undesirable things even on the legacy video output with the VGA core and a stock crystal, so nothing good happens without that 28MHz crystal.

Edited March 23 by flashjazzcat