1501 replies to this topic

[MARIO130XE]

Thanks!

Also: if uflash IDs the hardware by recognising the original BIOS and then you flash an entire ROM which contains the new BIOS, it may be that the BIOS update is overlooked. Reboot immediately following the full ROM update. I guess the flasher should re-identify the hardware after a full ROM flash, given the BIOS may have changed.

 I have restarted the Altirra. I have the boot loop problem even if i directly attach your ULTIMATE.ROM file from the 1st post as firmware for the U1mb emulation. (v0.24) No uflash was used. simply using the rom file and still having a boot loop problem. i have used an untouched (clear ini file) Altirra... same problem. 

[flashjazzcat]

I have restarted the Altirra. I have the boot loop problem even if i directly attach your ULTIMATE.ROM file from the 1st post as firmware for the U1mb emulation. (v0.24) No uflash was used. simply using the rom file and still having a boot loop problem. i have used an untouched (clear ini file) Altirra... same problem.

Which Altirra version are you using? I just directly attached Ultimate1MBv2afterflash.rom in Altirra 2.70-Test 18 here and everything appears to work. Anything peculiar about the emulator configuration?

 

BTW: did you set BIOS options as required and then hit "B" (Save and boot)? Setup will repeatedly appear on boot until you've done this (as the original BIOS did), since until then, the NVRAM checksum is invalid.

Edited by flashjazzcat, Wed Jul 15, 2015 5:08 AM.

[MARIO130XE]

OMG ... THANK YOUUUUUUUUUU!!!!! I have tried version 2.5 and 2.6 .... no luck but now in 2.7 Test18 it's working.

 

Seems I can play a bit in the emulator and then test it on real hardware.

 

Thanks and greetings, Mario

[flashjazzcat]

Great stuff: thanks for letting us know. I must have exploited one of the recent Ultimate emulation fixes.

[MARIO130XE]

.... I must have exploited one of the recent Ultimate emulation fixes.

Haha, yeahhh maybe.  

[flashjazzcat]

Anyone else get an unwanted coldstart on reset in Colleen mode on the Incognito (with the original BIOS and SDX enabled)?

Well - that's cleared up now, thanks to Phaeron and Hias. Both old and new BIOSes were jumping straight to the OS coldstart code on Reset in Colleen mode.

[fujidude]

zapped

Edited by fujidude, Wed Jul 15, 2015 8:39 AM.

[flashjazzcat]

Now that the reboot bug is fixed and since Roy's impression was pretty favourable, might as well push out the Incognito Beta:

 Incognito Beta BIOS 0.27.zip   724.61KB   229 downloads

All the previous caveats still apply: if you don't have some means of recovering from a bricked board, you might want to skip it. Attempts not to err on the side of extreme caution always seem to result in at least one isolated casualty, so best have a USB programmer to hand just in case. The Incognito is built from the exact same source as the Ultimate BIOS - with some conditional assembly deviations - so the UI, High-Speed SIO, and PBI BIOS should be pretty solid.

Couple of bug fixes in the supplied version of uFlash as well.

[morelenmir]

I didn't want to say anything until I had read more and also waited to see if others experience the same problem.  However, I must now report I am having no luck with the new BIOS in "Altirra".  The problem is a little similar to what MARIO130XE reported, except without the boot-cycle - I think.

 

My configuration at the "Altirra" levels:

Devices: (P:) Printer, (H:) Host Device

Hardware:  600XL/800XL

Firmware:  Stock '800XL and early 65XE' as verified by the 'Atari ROM Checker.jar' utility (MD5:06DAAC977823773A3EEA3422FD26A703)

Acceleration:  SIO Override Detection, P: (Printer CIO), CIO Burst Transfers

Memory Config:  Ultimate 1MB (obviously!)

Video:  PAL, VBXE (FX1.24 core), No Artifacting, Standard Video,

Audio:  Stereo, Non-linear Mixing, Channels 1-4

Hard Disk:  SIDE2.

 

I use the 'UFlash.XEX' that comes with the v0.24 beta release, and update only the 'BIOS' 'PBI BIOS' entries.  Everything else is identical to the old release, including SDX447, ROM slots, GAME slots and the rest.  When I first 'Reboot' from inside 'UFlash', immediately after flashing the new ROM code and after setting the 'SDX size at 256k' the simulation seems to work properly.  However, once I 'System Reset+Help' up to the BIOS menu, update the new settings to the correct values (where possible) and then use the 'Save Changes and Boot' option I simply get a black screen.  Perhaps this is actually is the same 'boot cycle' that MARIO130XE experienced?  All I can do is press 'Help', which instantly brings back the BIOS Menu.  Nothing changes if I cold reset "Altirra" nor indeed exit the emulator altogether and restart - after saving the new ROM image of course and telling "Altirra" to use it by default.

 

Interestingly, when I enter the "System Clock and Features" menu the 'VBXE' entry is both greyed out and set at disabled despite being enabled and unchanged since before the reflash.  Also strange is that, despite using the stock XL BIOS firmware at the emulator level, the "System Information" menu claims the machine is a 'XEGS (PAL)' and that again the 'VBXE Core' is 'Not Present'.

 

I have included the ROM images I am using; 'v2.0' before re-flashing and 'v2.4' afterwards.

 

Update:

 

Scratch all that.  A little irritated, I scrubbed over my whole Altirra installation and copied fresh OS ROMS and the works along with a new copy of the recent 'test 18'.  I clearly had some kind of Frankenstein's monster of builds in place because after that clean start the BIOS is now working properly as it should and no longer hangs at a black screen.  It also correctly identifies the VBXE...  Seeing as "Altirra" is pretty much self-contained it is odd how that might have happened; one way or another however I clearly had a corrupted build.  Perhaps I only thought I had updated the other week, but I am pretty sure I did.  Bugger - there's about a six days of dithering around wasted!!!  Nevermind.  Whatever the case the new version of "Altirra" and new the "Ultimate1MB" BIOS seem to work properly.  I am very tempted to flash this to the real hardware...  But I think I will still wait for my USB programmer to come.

Attached Files

•  Ultimate1MB ROM Images.rar   265.06KB   181 downloads

[spookt]

Now that the reboot bug is fixed and since Roy's impression was pretty favourable, might as well push out the Incognito Beta:

Incognito Beta BIOS 0.27.zip

All the previous caveats still apply: if you don't have some means of recovering from a bricked board, you might want to skip it. Attempts not to err on the side of extreme caution always seem to result in at least one isolated casualty, so best have a USB programmer to hand just in case. The Incognito is built from the exact same source as the Ultimate BIOS - with some conditional assembly deviations - so the UI, High-Speed SIO, and PBI BIOS should be pretty solid.

Couple of bug fixes in the supplied version of uFlash as well.

Woop!

 

Updated. New config screens are fantastic. Sitting down to read the manual now (after the fact obviously!)

[morelenmir]

One question I do have is regarding the new fast IO code.  I thought in order to get it chugging along better than 19kbps you had to physically modify the motherboard - yank off a couple of capacitors and install a resister between two pins on the SIO socket itself?  Is it possible to do the same from software then?

[Madi]

I didn't want to say anything until I had read more and also waited to see if others experience the same problem.  However, I must now report I am having no luck with the new BIOS in "Altirra".  The problem is a little similar to what MARIO130XE reported, except without the boot-cycle - I think.

.

.

.

 

I have included the ROM images I am using; 'v2.0' before re-flashing and 'v2.4' afterwards.

 

 

I tested the ROM image (v2.4) under Altirra 2.70 test 18.

Similar setup was used. It works just fine. I even tried several options such as High speed SIO (drives 1-4). No problems found.

 

Madi

 

EDIT

 

morelenmir : Nice to read that you had figured it out.

Edited by Madi, Wed Jul 15, 2015 4:09 PM.

[Kyle22]

One question I do have is regarding the new fast IO code.  I thought in order to get it chugging along better than 19kbps you had to physically modify the motherboard - yank off a couple of capacitors and install a resister between two pins on the SIO socket itself?  Is it possible to do the same from software then?

Many if not most will run up to 68K or so before you run into issues.  I have used Indus GT's on computers without removing capacitors.  However, I installed a FIFO buffer under PoKey in a 1200XL, and it hardly worked at all until I removed the caps, then it worked like a charm.

 

No, it is not possible to remove the caps via software.  I recommend removing them from all models regardless of what SIO speed I'm using now because in the future I may want to go faster.

[morelenmir]

Many if not most will run up to 68K or so before you run into issues.  I have used Indus GT's on computers without removing capacitors.  However, I installed a FIFO buffer under PoKey in a 1200XL, and it hardly worked at all until I removed the caps, then it worked like a charm.

 

No, it is not possible to remove the caps via software.  I recommend removing them from all models regardless of what SIO speed I'm using now because in the future I may want to go faster.

 

I will do that I think the next time I have the lid off.  It interested me how the hardware mod - more or less essential by all sounds - tallied with the software patch in FJC's new BIOS.

[morelenmir]

I have a - very - minor UI suggestion in regards the BIOS screen.  On the 'PBI BIOS Setup Screen' we are given a scroll bar on the right hand side.  It took me a while to understand why I could not get the paine to scroll and in fact wrote it off as part of my earlier problems.  Obviously, I now realize it only becomes useful when the extra options are enabled that pertain to the 'High-speed SIO" entry.  I suggest the UI allows you to scroll over those entries, even when disabled and not just roll back to the top of the screen.  Alternately perhaps the scrollbar can be in some way visually disabled along with the off-page items - or even vanishes all together.  As things stand it doesn't quite make logical visual sense.

[flashjazzcat]

I have a - very - minor UI suggestion in regards the BIOS screen.  On the 'PBI BIOS Setup Screen' we are given a scroll bar on the right hand side.  It took me a while to understand why I could not get the paine to scroll and in fact wrote it off as part of my earlier problems.  Obviously, I now realize it only becomes useful when the extra options are enabled that pertain to the 'High-speed SIO" entry.  I suggest the UI allows you to scroll over those entries, even when disabled and not just roll back to the top of the screen.  Alternately perhaps the scrollbar can be in some way visually disabled along with the off-page items - or even vanishes all together.  As things stand it doesn't quite make logical visual sense.

Prowizard already made a similar observation and recommendation to me during alpha testing, and it's a reasonable observation. However, it's harder than it might seem to do anything about it, so I left it as it is. Since scrolling is driven by the selection bar, and the selection bar (necessarily) cannot alight upon a dimmed menu item, the list view is never adjusted so that it reveals the four disabled items at the bottom of the menu if High-Speed SIO is off. So logic might dictate that the scroll bar, then, becomes superfluous... but I don't know about that. In - for example - a Windows scrolling list, if random list items were greyed out/not selectable, you'd still be able to view the entire list by dragging the scroll thumb with the mouse to reveal the entire list. Of course we can't do that in the BIOS, since the keyboard/joystick always drives the selection bar only. I'm guessing if you used the keyboard to drive the Windows selection bar in said list, you'd see similar behaviour (although I have not checked).

Aside from this, re-establishing the size of the list on the basis of deactivated items at its head or tail in order to deactivate the scroller is a surprisingly kludgy process, and I thought I'd better devote the few remaining bytes of code space to something more useful. The scroll bar was itself a late addition whose sole purpose was to alert the user to the fact there are more than eight items in the menu. Ironically when there are no selectable items at all in a menu with more than eight items, keyboard up/down drives the view offset, although no such menu currently exists.

[morelenmir]

Prowizard already made a similar observation and recommendation to me during alpha testing, and it's a reasonable observation. However, it's harder than it might seem to do anything about it, so I left it as it is. Since scrolling is driven by the selection bar, and the selection bar (necessarily) cannot alight upon a dimmed menu item, the list view is never adjusted so that it reveals the four disabled items at the bottom of the menu if High-Speed SIO is off. So logic might dictate that the scroll bar, then, becomes superfluous... but I don't know about that. In - for example - a Windows scrolling list, if random list items were greyed out/not selectable, you'd still be able to view the entire list by dragging the scroll thumb with the mouse to reveal the entire list. Of course we can't do that in the BIOS, since the keyboard/joystick always drives the selection bar only. I'm guessing if you used the keyboard to drive the Windows selection bar in said list, you'd see similar behaviour (although I have not checked).

Aside from this, re-establishing the size of the list on the basis of deactivated items at its head or tail in order to deactivate the scroller is a surprisingly kludgy process, and I thought I'd better devote the few remaining bytes of code space to something more useful. The scroll bar was itself a late addition whose sole purpose was to alert the user to the fact there are more than eight items in the menu. Ironically when there are no selectable items at all in a menu with more than eight items, keyboard up/down drives the view offset, although no such menu currently exists.

 

Its a question of cramming it all in to the space available isn't it!  Maybe an ideal solution would be to separate the High-Speed IO options to their own paine - but that would probably use up more memory than the code to fix the scrollbar as it stands.

[Kyle22]

I think the scrolling issue is, in reality, a non-issue.  It doesn't bother me at all.

 

My only question (at this point) is: How does the BIOS determine if it is running on an XEGS so it enables XEGS slot selection?

 

I haven't been able to test this on my real hardware yet.  I wired my 1200XL to be XEGS compatible, and the old BIOS XEGS selections work fine.  Will the new BIOS work on it?

[flashjazzcat]

It's partly a question of cramming it into the available space, and partly a question of my not being completely convinced by any of the suggestions about how it should work. If there was a single un-dimmed item beyond those greyed-out SIO options, you'd still be able to cursor down and see the dimmed SIO entries, so the scroll bar would still be appropriate. If dimmed options actually disappeared altogether, meanwhile, it would make sense to consider the list truncated if the last four options were greyed out, but dimmed items remain visible elsewhere, so it's kind of not.

One compromise would be to scroll the menu at an earlier point: perhaps when the selection bar hits the second or third from last visible item in a scrollable menu. You'd then get to see some (though not all) or those scrolling, unreachable items. I think this only seems like an issue because all four off-screen items happen to grey out and thus prevent even a partial scroll from occuring. The reason a fix isn't simple to effect is that the menu handler operates on generic menu data: I am unwilling to simply hard-code deactivation of the scroll bar if HiSIO is globally disabled. That's a case of coding practice coming face-to-face with reality.

Anyway: usability and presentation are important here as anywhere else, so I'll give it some thought.

[morelenmir]

I think the scrolling issue is, in reality, a non-issue.  It doesn't bother me at all.

 

My only question (at this point) is: How does the BIOS determine if it is running on an XEGS so it enables XEGS slot selection?

 

I haven't been able to test this on my real hardware yet.  I wired my 1200XL to be XEGS compatible, and the old BIOS XEGS selections work fine.  Will the new BIOS work on it?

 

Its purely a usability thing kyle22, not important at all - it just happened to stick in my mind because it tripped me up when I was first using the new BIOS.

 

In regards the XEGS/XEGM thing...  That is an excellent question!  On "Altirra', even if you set the emulation to run as a XEGS system and flash a XEGM OS to one of your OS ROM slots then select that slot from within the BIOS menu as your OS of choice... the 'XEGS Slot' option remains disabled.

 

On the actual "Ultimate1MB" hardware there is a jumper-bridge to short if you want XEGS support, but I have not flashed the new BIOS yet so cannot tell you how it works in the real setting.

[rdea6]

On the actual "Ultimate1MB" hardware there is a jumper-bridge to short if you want XEGS support, but I have not flashed the new BIOS yet so cannot tell you how it works in the real setting.

Real hardware not working for XEGS slot   But if you set it up and do the correct key press the first slot game will boot and play..

[flashjazzcat]

My only question (at this point) is: How does the BIOS determine if it is running on an XEGS so it enables XEGS slot selection?

Thank Phaeron for this, since testing for the XEGS was his suggestion. On the XEGS, bit 6 of PORTB maps in the game ROM. So the BIOS attempts to map in the ROM and then tests for RAM in the cart window. An additional issue was ensuring that SDX and the external cart are both out of the way so we can test for RAM. We need to do this without hitting the SDX banking register, too, otherwise we risk breaking external carts. Fortunately, I remembered that the SIDE ATR button enable bit maps out the external cart, so it's possible to non-destructively ensure that the XEGS ROM is the only thing being tested.

I wired my 1200XL to be XEGS compatible, and the old BIOS XEGS selections work fine.  Will the new BIOS work on it?

The original BIOS doesn't test for XEGS configuration. The new BIOS should work fine. In addition, it would be nice to hear from owners of actual XEGS machines with Ultimate fitted and configured for that machine.

[flashjazzcat]

Real hardware not working for XEGS slot   But if you set it up and do the correct key press the first slot game will boot and play..

Can you elucidate on this a little Roy... I'm not understanding the second bit.

[rdea6]

Well with the XEGS rom selected as the rom slot and the XEGS pins jumped on the Ultimate THEN the SELECT+RESET like the original XEGS console the game will start and be playable.  I use the second Bios [P] to activate  SDX off HDD off PBI off

[flashjazzcat]

Right. So let me get this straight: when Ultimate is jumpered for XEGS mode, the XEGS slot is visible and editable - right? So the hardware detection is working? If not, I need to know... but it seems it is.

 

I'm not overly familiar with the XEGS. I assumed the game ROM booted when the machine was powered up with the keyboard removed.

 

So what is not working as expected? I need the info.