Altirra 3.10 released

[+Nezgar]

At the physical layer, MIDI is simply an asyncronous serial port at 31250bps, 8 bits, no parity, 1 stop bit.

 

Used to use it on the ST for null modem transfers and some games between 2 computers because it was faster than the 19200bps limit of the original ST serial ports.

[rensoup]

I've recently started a bit dev on the A8 and I'm using Altirra for debugging and while it's working pretty well overall, there are a few things that could help:

 

Could I make the debug fonts (much) bigger ? i tried the /portable switch which created an .ini file which has fonts settings but don't seem to do anything ?

 

Is there a command switch to automatically load the .lst file because I'm using Alt-Shift-O every time ?

 

Although I'm using an obj file right now, I'm planning on using xBios to be able to use the whole memory space as well as loading extra data. So that means an ATR file.

Any way making the loading time instant ? not like warp speed where everything get speed up (although I guess I could use it if I could bind it to a key).

Or perhaps there's a way to mount a directory as if it was an ATR?

 

Thanks

[phaeron]

Could I make the debug fonts (much) bigger ? i tried the /portable switch which created an .ini file which has fonts settings but don't seem to do anything ?

 

Debug > Options > Change Font.

 

Is there a command switch to automatically load the .lst file because I'm using Alt-Shift-O every time ?

 

The emulator will load .lab and .lst files with the same name by default, but this won't work if you are loading the executable in code instead of letting the emulator do it. You can use a breakpoint to trigger the .loadsym command, or use .reload to reload the symbol file that has already been loaded.

 

Although I'm using an obj file right now, I'm planning on using xBios to be able to use the whole memory space as well as loading extra data. So that means an ATR file.

Any way making the loading time instant ? not like warp speed where everything get speed up (although I guess I could use it if I could bind it to a key).

xBIOS is a custom loader, so this depends on how much of what it is doing is visible to the emulator. It looks like the default configuration used by the xBIOS menu is to load sectors through SIOV, which the emulator can speed up to zero time when the D: SIO patch is enabled.

 

However, configuring it to use its own I/O module will bypass this and prevent the emulator from seeing the disk read request to accelerate it. In that case, the best you can do is to enable D: burst I/O, which will cause the emulator to feed bytes to the SIO read routine as fast as it can handle them. This will be close to zero time but still bottlenecked by the rate that the 6502 can read the bytes. You will also want to make sure that accurate sector timing is disabled in the emulator, or else it will simulate rotational delays on the disk.

 

By the way, the current version of xBIOS (4.3) still does not implement burst I/O and is copying a byte at a time from the I/O buffer to the load address instead of loading sectors directly. On an actual 1050 floppy disk drive, this causes it to miss sectors and load at two-thirds speed compared to DOS 2.0S.

 

Or perhaps there's a way to mount a directory as if it was an ATR?

 

There is. In the Disk Drives dialog, there is a small triangle you can click to select "mount folder as virtual DOS 2 disk."

 

[rensoup]

 

Debug > Options > Change Font.

 

Damn I somehow missed that... Much better now

 

Might there be a color setting that I missed too (the white background is a little harsh) ?

 

 

The emulator will load .lab and .lst files with the same name by default, but this won't work if you are loading the executable in code instead of letting the emulator do it. You can use a breakpoint to trigger the .loadsym command, or use .reload to reload the symbol file that has already been loaded.

 

I'm loading from the command line and I wasn't paying attention again because it does indeed load the symbols... but it doesn't have all the comments that I wrote in the source (I still have to use Sh-Alt-O for that )... comments should be loaded from the lst file, right ?

 

 

 

By the way, the current version of xBIOS (4.3) still does not implement burst I/O and is copying a byte at a time from the I/O buffer to the load address instead of loading sectors directly. On an actual 1050 floppy disk drive, this causes it to miss sectors and load at two-thirds speed compared to DOS 2.0S.

 

That sounds like a dealbreaker...

[phaeron]

Might there be a color setting that I missed too (the white background is a little harsh) ?

Nope, Altirra generally uses the system theme color settings including the window background color. Blame Microsoft for removing the UI in Windows 10 to configure theme colors and not updating the theme colors when dark mode is enabled in the system. I've thought about overriding this but it's a mess with dark mode not being properly exposed to Win32 and some system controls still using unconfigurable colors and theme images.

 

I'm loading from the command line and I wasn't paying attention again because it does indeed load the symbols... but it doesn't have all the comments that I wrote in the source (I still have to use Sh-Alt-O for that )... comments should be loaded from the lst file, right ?

 

No, Altirra only the parses the address/opcode bytes and line numbers from the listing and uses the source field only for looking for special directives. It does not try to parse the assembly lines, which is not trivial (consider that semicolons can be embedded in string literals).

 

[flashjazzcat]

I'd never considered dark mode in relation to Altirra before, but now it's been mentioned, dark mode in Altirra is all I can think about.

[rensoup]

 

Nope, Altirra generally uses the system theme color settings including the window background color. Blame Microsoft for removing the UI in Windows 10 to configure theme colors and not updating the theme colors when dark mode is enabled in the system. I've thought about overriding this but it's a mess with dark mode not being properly exposed to Win32 and some system controls still using unconfigurable colors and theme images.

 

Well I'm still stuck on W8 I was asking for a dark background colour in debug windows not necessarily something that strictly follows windows conventions.

I thought that'd be an easy change but I'm not a Windows expert. I've only ever used Winforms and it's easy with those.

 

 

No, Altirra only the parses the address/opcode bytes and line numbers from the listing and uses the source field only for looking for special directives. It does not try to parse the assembly lines, which is not trivial (consider that semicolons can be embedded in string literals).

 

maybe I phrased that wrong again. I'm already using source debugging with Alt-Sh-O and it works great. It just doesn't seem to default to using it and I have to use ALT-Sh-O, then point to the masm file to activate it.

I was hoping it would do this automatically but that's not a big deal if it doesn't.

 

 

[+Nezgar]

Something I noticed when saving screenshots... No matter how many colours are on the screen, Altirra always saves PNG's with 8 bits per pixel, when often, 4, or 2 bits will do.

 

Not that Altirra needs to be able to encode PNG with brute force optimization to attain the best compression, but just reduce the encoded palette to the next minimum that covers the requirements might achieve some savings...

 

Not critical. Maybe a limitation of the save library. Paint.NET seems to have this same limitation. (8 bit PNG minimum)

 

 

Example output processing two GR.0 screenshots with OptiPNG (Black background, Blue text area, white text = 3 colours)

** Processing: M:\DOS25_SETUP.png
336x224 pixels, 3x8 bits/pixel, RGB
Reducing image to 2 bits/pixel, 3 colors in palette
Input file size = 4192 bytes
Output file size = 1350 bytes (2842 bytes = 67.80% decrease)

** Processing: M:\DOS25_SETUP_AUTORUN.png
336x224 pixels, 3x8 bits/pixel, RGB
Reducing image to 2 bits/pixel, 3 colors in palette
Input file size = 5092 bytes
Output file size = 1735 bytes (3357 bytes = 65.93% decrease)

[phaeron]

Update:
http://www.virtualdub.org/beta/Altirra-3.20-test24.zip
http://www.virtualdub.org/beta/Altirra-3.20-test24-src.zip

 

• XF551 standard emulation mode now forces single density when the current mode is enhanced density and the regular $21 format command is issued.
• .readmem and .writemem debugger commands now accept quoted paths.
• Fixed broken DB 32K cartridge banking mode.
• Fixed The!Cart $8000-9FFF window using the secondary banking window's read/write bit in 16K banking modes. The primary banking window's R/W enable bit is now used.

maybe I phrased that wrong again. I'm already using source debugging with Alt-Sh-O and it works great. It just doesn't seem to default to using it and I have to use ALT-Sh-O, then point to the masm file to activate it.
I was hoping it would do this automatically but that's not a big deal if it doesn't.

 

You can do Go To Source from the disassembly or history windows and the debugger will attempt to open the source file. Current test releases also have the Source File List option. The debugger doesn't default to source mode because the assemblers don't always emit reliable debugging information, especially with includes, macros, and compound statements.

Something I noticed when saving screenshots... No matter how many colours are on the screen, Altirra always saves PNG's with 8 bits per pixel, when often, 4, or 2 bits will do.

 

The PNG encoder currently always emits truecolor, it doesn't attempt to reduce to indexed color. It could do so, but I haven't bothered much because I always use pngquant or pngcrush in a case where I really care about size.

 

Also, if the image can be reduced to indexed color, it almost certainly means that the image is using the wrong aspect ratio for NTSC since the correct aspect ratio requires resampling that invariably increases the unique color count past 256. This is only generally possible with square pixels, no scanlines, and no artifacting.

 

 

[Faicuai]

I have spent quite some time running Altirra's OS suite / pack on actual HW (initial tests on Incognito), and found some issues that may definitely be worth looking at:

 

1. Altirra OS for 800 locks up / fails to boot on actual 800 / Incognito hardware. All other OS/a, OS/b, with or without Newell FP variants run flawlessly. This has been a persistent problem since 3.10. No change of settings on BIOS menu (RAM size, SDX, Basic Cart, etc.) seem to mitigate the problem. There is not even a way to get to the SIDE Loader utility, "L" leads to the same black-screen (crash / lock-up). It DOES work well on the emulator, though.
2. Altirra OS for XL locks up / crashes right after accessing any SIO-based unit (and issuing a "dir" command), when loading PCLINK.SYS driver during CONFIG.SYS processing. When booting WITHOUT IT and then loading it manually from SDX prompt, it DOES NOT crash (!!??). All other OS variants (XL r03, r04, etc.) work flawlessly, without a problem, by loading PCLINK at any point.
3. Fast Basic v4.1 (Beta) crashes under Altirra OS / XL and SDX, if (yet again) QuickED E: accelerator is loaded. In FB's latest fix, it now works perfectly under all other OS variants (XL r03, r04, etc.)

Not sure if you have already addressed these, but could not find relevant info. If not, they may be worth taking a look at...

 

BTW, the Altirra's OS line-fill-operation / primitive is RIDICULOUSLY fast, in relative terms to oem OS... Plenty of sweetness under the hood !

[phaeron]

I have spent quite some time running Altirra's OS suite / pack on actual HW (initial tests on Incognito), and found some issues that may definitely be worth looking at:

 

1. Altirra OS for 800 locks up / fails to boot on actual 800 / Incognito hardware. All other OS/a, OS/b, with or without Newell FP variants run flawlessly. This has been a persistent problem since 3.10. No change of settings on BIOS menu (RAM size, SDX, Basic Cart, etc.) seem to mitigate the problem. There is not even a way to get to the SIDE Loader utility, "L" leads to the same black-screen (crash / lock-up). It DOES work well on the emulator, though.
2. Altirra OS for XL locks up / crashes right after accessing any SIO-based unit (and issuing a "dir" command), when loading PCLINK.SYS driver during CONFIG.SYS processing. When booting WITHOUT IT and then loading it manually from SDX prompt, it DOES NOT crash (!!??). All other OS variants (XL r03, r04, etc.) work flawlessly, without a problem, by loading PCLINK at any point.
3. Fast Basic v4.1 (Beta) crashes under Altirra OS / XL and SDX, if (yet again) QuickED E: accelerator is loaded. In FB's latest fix, it now works perfectly under all other OS variants (XL r03, r04, etc.)

Not sure if you have already addressed these, but could not find relevant info. If not, they may be worth taking a look at...

 

For the first one, not sure and I can't test against Incognito. Did you have a previous version that did work? Knowing the last working version will help as I can narrow it down to a range of changes in source control history. BASIC cart not helping rules out memory sizing at least, and PIA initialization should be OK.

 

For the third one, confirmed. It's an issue with the QuickEd driver, with FastBasic just triggering the problem by temporarily disabling the cursor. What's happening is that QuickEd relies on undocumented meaning of the OLDADR variable when the cursor is hidden, and the way that AltirraOS maintains this variable causes QuickEd to write to random locations in page zero. I think I can rewrite the code to work around this but it'll probably have to wait until post 3.20. For now, don't use QuickEd with AltirraOS even if it appears to work.

 

For the second one, I wasn't able to reproduce this, but if you had QuickEd running it might contribute to problems. Otherwise, it would be helpful to know what specific versions of SpartaDOS X and the PCLink driver you were using.

[Faicuai]

 

For the first one, not sure and I can't test against Incognito. Did you have a previous version that did work? Knowing the last working version will help as I can narrow it down to a range of changes in source control history. BASIC cart not helping rules out memory sizing at least, and PIA initialization should be OK.

 

For the third one, confirmed. It's an issue with the QuickEd driver, with FastBasic just triggering the problem by temporarily disabling the cursor. What's happening is that QuickEd relies on undocumented meaning of the OLDADR variable when the cursor is hidden, and the way that AltirraOS maintains this variable causes QuickEd to write to random locations in page zero. I think I can rewrite the code to work around this but it'll probably have to wait until post 3.20. For now, don't use QuickEd with AltirraOS even if it appears to work.

 

For the second one, I wasn't able to reproduce this, but if you had QuickEd running it might contribute to problems. Otherwise, it would be helpful to know what specific versions of SpartaDOS X and the PCLink driver you were using.

 

Here you go:

 

1. Never tested before v3.10, and it never worked since then. All other 800-based OSes that I have flashed work perfectly on Incognito. With your replacement OS, you IMMEDIATELY get a blank / black screen as soon as you hit "B" for booting (flashing on any slot). No matter what BIOS settings, it just crashes up-front. Like reading or setting some HW registers that the original OS does not touch or not in the same sequence?
   • NOTE:
     • the only similar case I experienced such black-out at boot-time, was when flashing OS/B PAL. As soon as you hit "B" from BIOS, you hear a "click" on the 800 internal speaker (while screen is still black), and then NOTHING else happens.
     • Just in case, watch when using / reading $D013 and its mirrored values down in RAM (#03FA). $D013 (and 33, 53, 73, 93, B3, D3, F3) all read fuzzy on Incognito, where most of the times you find a $D0 in there, and *some* other times you find a range of random values. This is TRIGx, followed by GINTLK ($03FA). In fact, if you ever try to write back anything on #03FA, current OEM OS (XL) locks op on Incognito (!).
2. I dug a lot deeper on the PCLINK issue and it is just a cascading issue that does not really originate with it. It starts with QUICKED.SYS, and here's the test and trigger sequence for you:
   1. Need SDX 4.49c
   2. Config.sys:
      • USE BANKED
      • DEVICE SPARTA
      • DEVICE SIO
      • DEVICE ATARIDOS
      • DEVICE ULTIME
      • DEVICE QUICKED
   3. Boot into SDX, and then load Last Word with X /c util.
   4. Hit Control-D for directory on LW, browse files, etc., and then SHFT-CTRL-Q
   5. You should be back at SDX prompt. Enter "DIR".
   6. E: corruption appears (halves of screen inverted) and systems crashes shortly after.
   7. As counter test, remove "DEVICE QUICKED" from above, and test will pass.
   8. NOTE: NO PROBLEMS with OEM r3/r4 XL/XE OS'es. Seems conflict with E: and yours (?)

 

If you need any help or support from me, let me know, and I will everything I can.

 

Cheers!

Edited May 16, 2019 by Faicuai

[flashjazzcat]

Dumb question: you are running the Incognito in Colleen mode, right?

[Faicuai]

Dumb question: you are running the Incognito in Colleen mode, right?

 

For OS-a/b type of OS, of course (only place and way to test 10240-bytes roms).

 

All other tests above, per OS-type noted.

[phaeron]

Never tested before v3.10, and it never worked since then. All other 800-based OSes that I have flashed work perfectly on Incognito. With your replacement OS, you IMMEDIATELY get a blank / black screen as soon as you hit "B" for booting (flashing on any slot). No matter what BIOS settings, it just crashes up-front. Like reading or setting some HW registers that the original OS does not touch or not in the same sequence?

 

It does write hardware registers in a different order, but that's a necessity since it is an independent reimplementation. Pretty much all OSes write at least $00 to all registers though as part of hardware initialization, as it's the simplest to do and now also required for VBXE to reset. If it is hardware register related, it'd have to be specific patterns and not just which registers are hit.

 

Just in case, watch when using / reading $D013 and its mirrored values down in RAM (#03FA). $D013 (and 33, 53, 73, 93, B3, D3, F3) all read fuzzy on Incognito, where most of the times you find a $D0 in there, and *some* other times you find a range of random values. This is TRIGx, followed by GINTLK ($03FA). In fact, if you ever try to write back anything on #03FA, current OEM OS (XL) locks op on Incognito (!).

 

AltirraOS won't be affected as it doesn't use TRIG3 except to initialize GINTLK for XEGS cartridge compatibility, and doesn't implement the super-annoying GINTLK lockup.

 

This behavior wouldn't really cause problems for 800 OSes besides some joystick-based software malfunctions, but it seems impossibly broken for XL/XE mode. The XL/XE OS doesn't even mask TRIG3, it stores and compares all 8 bits against GINTLK. I don't see how this behavior wouldn't cause an immediate lockup.

 

The reason you would be getting mostly $D0 would be when running code from RAM that reads it with an LDA $D013 instruction. The $D0 is the last byte of the instruction, held on the floating bus by capacitance, except when ANTIC does a DMA cycle in between and you get its data instead. However, I can't see from the FPGA source how you would be getting open bus for a TRIG3 read. In 800 mode, the MMU logic maps all of $D000-D0FF to GTIA and tri-states its own TRIG3 output, while in XL/XE mode it punches out $D013+$20*N from GTIA and handles TRIG3 itself.

 

[+Nezgar]

The PNG encoder currently always emits truecolor, it doesn't attempt to reduce to indexed color. It could do so, but I haven't bothered much because I always use pngquant or pngcrush in a case where I really care about size.

 

Also, if the image can be reduced to indexed color, it almost certainly means that the image is using the wrong aspect ratio for NTSC since the correct aspect ratio requires resampling that invariably increases the unique color count past 256. This is only generally possible with square pixels, no scanlines, and no artifacting.

You are correct I incorrectly stated it saves 8-bit, it is indeed 3x8bit (24 bit)

 

And yes, the examples I was working with were indeed using no aspect ratio correction, so no resampling/resizing specifically to get the lowest file size, exact minimum colour count, and 1:1 pixel ratio. Indeed, any other mode would likely result in more than 256 as you stated.

 

Thanks for the explanation. I will continue to use an external optimizer when the need arises.

[phaeron]

Update:

http://www.virtualdub.org/beta/Altirra-3.20-test25.zip

http://www.virtualdub.org/beta/Altirra-3.20-test25-src.zip

 

• Compiler updated to VS2017 15.9.12.
• Fixed definition of 2M MegaCart (CAR type 64).
• Another banking fix for The!Cart.

[Keatah]

FEATURE SUGGESTION:

 

How about a variable-speed warp? With 4 & 5GHz processors being mainstream options these days, unlimited warp speed (F1) can blast you through levels in fractions of a second. Whereas old-school processors would get you 5x or 10x speedup. While 300x speedup is funny and amusing, it is actually less practical.

[Faicuai]

 

It does write hardware registers in a different order, but that's a necessity since it is an independent reimplementation. Pretty much all OSes write at least $00 to all registers though as part of hardware initialization, as it's the simplest to do and now also required for VBXE to reset. If it is hardware register related, it'd have to be specific patterns and not just which registers are hit.

 

 

AltirraOS won't be affected as it doesn't use TRIG3 except to initialize GINTLK for XEGS cartridge compatibility, and doesn't implement the super-annoying GINTLK lockup.

 

This behavior wouldn't really cause problems for 800 OSes besides some joystick-based software malfunctions, but it seems impossibly broken for XL/XE mode. The XL/XE OS doesn't even mask TRIG3, it stores and compares all 8 bits against GINTLK. I don't see how this behavior wouldn't cause an immediate lockup.

 

The reason you would be getting mostly $D0 would be when running code from RAM that reads it with an LDA $D013 instruction. The $D0 is the last byte of the instruction, held on the floating bus by capacitance, except when ANTIC does a DMA cycle in between and you get its data instead. However, I can't see from the FPGA source how you would be getting open bus for a TRIG3 read. In 800 mode, the MMU logic maps all of $D000-D0FF to GTIA and tri-states its own TRIG3 output, while in XL/XE mode it punches out $D013+$20*N from GTIA and handles TRIG3 itself.

 

 

THANKS!

 

In any case, the 800-OS replacement needs a second look, for sure. It is not initializing correctly (as far as I can tell / see). I would really like to try it and put it through its paces.

 

Now, moving to another context, I took some time to go back to my 800XLs Ultimate, and what is interesting about Trig3 and GINTLK is that $D013 (and family) read a SOLID, STEADY value, that WILL pass OS TRIG3 / GINTLOCK evaluations.

 

The bottom-line with this issue is that OEM OS (as it is written) and running on Incognito, WILL NOT be able to reliably soft-reset (at times, a "system reset" button will be processed as warm, and at another times, the same event will be processed as a COLD / FULL. This is because fluctuating values of $D013. Which means the OS (original) vectors for warm-reset DO NOT work as intended. Only viable way I found to address this without modifying original OS (and not modifying Incognito) is to pre-program PUPVL1-PUPVL3 & COLDST locations with correct values, and then send CPU to OSPWS1 handler in OS ($C2A1) which will ensure consistent, time-after-time soft-reset (I coded this in a small utility I normally invoke from SDX prompt and Atari DOS, when required).

Edited May 20, 2019 by Faicuai

[phaeron]

Attached is a modified version of AltirraOS/800 that shows background colors as it goes through init stages. Something sounds screwy hardware-wise, but I can't tell what change or workaround might be required until we figure out where the OS is stopping.

Now, moving to another context, I took some time to go back to my 800XLs Ultimate, and what is interesting about Trig3 and GINTLK is that $D013 (and family) read a SOLID, STEADY value, that WILL pass OS TRIG3 / GINTLOCK evaluations.

The bottom-line with this issue is that OEM OS (as it is written) and running on Incognito, WILL NOT be able to reliably soft-reset (at times, a "system reset" button will be processed as warm, and at another times, the same event will be processed as a COLD / FULL. This is because fluctuating values of $D013. Which means the OS (original) vectors for warm-reset DO NOT work as intended. Only viable way I found to address this without modifying original OS (and not modifying Incognito) is to pre-program PUPVL1-PUPVL3 & COLDST locations with correct values, and then send CPU to OSPWS1 handler in OS ($C2A1) which will ensure consistent, time-after-time soft-reset (I coded this in a small utility I normally invoke from SDX prompt and Atari DOS, when required).

 

Here's the thing: the XL/XE OS doesn't just compare TRIG3 and GINTLK on warm reset. It does it on every frame at the start of stage 2 VBLANK. It has to be at least stable then, or else the OS will lock up immediately. For the system to be giving varying values in TRIG3 and still being able to boot the XL/XE OS is a bit mysterious.

 

kernel.rom

[Faicuai]

Attached is a modified version of AltirraOS/800 that shows background colors as it goes through init stages. Something sounds screwy hardware-wise, but I can't tell what change or workaround might be required until we figure out where the OS is stopping.

 

 

Here's the thing: the XL/XE OS doesn't just compare TRIG3 and GINTLK on warm reset. It does it on every frame at the start of stage 2 VBLANK. It has to be at least stable then, or else the OS will lock up immediately. For the system to be giving varying values in TRIG3 and still being able to boot the XL/XE OS is a bit mysterious.

 

 

Bizarre....

 

The carnival-colors modified kernel crashes IMMEDIATELY as soon as Incognito Logo / Splash screens disappears.... NO COLORS, everything is as dark as Milky Way's black-hole.

 

(UPDATE: I have re-flashed ALL slots to OS A/B variants, verified they work one by one, and then flashed carnival-kernel on Slot 3, in the middle of everything.... then went booting SLOT by SLOT, and reached blackness as soon as I attempted third slot... so it is definitely something between that kernel and the machine)...

 

I can, however, see the show, on Altirra... Quite useful, indeed!

Edited May 21, 2019 by Faicuai

[phaeron]

Eh... if you can't even get to the yellow color with that ROM, then something is fundamentally wrong with either the way the image is being flashed or the way that control is being handed off from the BIOS. All that ROM does from reset to the first color is to initialize the stack, wait 0.1 seconds, and set WARMST. That's it. Are NMIs being left enabled or something?

[Faicuai]

Eh... if you can't even get to the yellow color with that ROM, then something is fundamentally wrong with either the way the image is being flashed or the way that control is being handed off from the BIOS. All that ROM does from reset to the first color is to initialize the stack, wait 0.1 seconds, and set WARMST. That's it. Are NMIs being left enabled or something?

 

It is perplexing, indeed... but the key question is how in the world it does work with oem OS A/B loads? What does the carnival version requires when transitioning out of BIOS that the oem version does not?

 

That is the key...

 

I also wonder if it works on a machine NOT equipped with Incognito (flashed on eprom on a stock personality board... that would be beyond my current means to test, though)

Edited May 21, 2019 by Faicuai

[phaeron]

I can't test on stock hardware either, unfortunately. I have an 800 but no way to flash a custom OS ROM.

 

OS-A/B clears NMIEN sooner, which may make the difference. All NMIs are supposed to start off on reset since the 6502 can't defend against them, which is why ANTIC automatically clears them on reset... but Incognito is a bit different since the BIOS executes first. Can you try the attached version? It clears NMIEN ASAP to reduce the window of vulnerability as much as possible should this be the issue.

 

kernel.rom

[Faicuai]

I can't test on stock hardware either, unfortunately. I have an 800 but no way to flash a custom OS ROM.

 

OS-A/B clears NMIEN sooner, which may make the difference. All NMIs are supposed to start off on reset since the 6502 can't defend against them, which is why ANTIC automatically clears them on reset... but Incognito is a bit different since the BIOS executes first. Can you try the attached version? It clears NMIEN ASAP to reduce the window of vulnerability as much as possible should this be the issue.

 

 

I can't make it work... I even toggled (enabled / disabled) SDX on Colleen profile (BIOS) as it sometimes blocks boot... but NO way out of that f-black screen. It is crashing right there on BIOS-exit.

 

A hint here is that hitting "L" will never take you to SIDE-Loader menu, it black-crashes, as well... I also plugged my original SALT diagnostics cart, and IT DOES not boot...

 

Edited May 21, 2019 by Faicuai