Jump to content

Photo

Altirra 3.10 released

altirra emulation

615 replies to this topic

#601 Nezgar OFFLINE  

Nezgar

    Stargunner

  • 1,963 posts
  • Location:Saskatchewan Canada

Posted Mon Apr 29, 2019 1:54 PM

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.

#602 rensoup OFFLINE  

rensoup

    Space Invader

  • 26 posts

Posted Sun May 5, 2019 7:11 AM

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



#603 phaeron OFFLINE  

phaeron

    River Patroller

  • Topic Starter
  • 2,764 posts
  • Location:Bay Area, CA, USA

Posted Sun May 5, 2019 2:07 PM

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."

 



#604 rensoup OFFLINE  

rensoup

    Space Invader

  • 26 posts

Posted Mon May 6, 2019 3:30 PM

 

Debug > Options > Change Font.

 

Damn I somehow missed that... Much better now :thumbsup:

 

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...



#605 phaeron OFFLINE  

phaeron

    River Patroller

  • Topic Starter
  • 2,764 posts
  • Location:Bay Area, CA, USA

Posted Mon May 6, 2019 9:30 PM

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).

 



#606 flashjazzcat ONLINE  

flashjazzcat

    Quadrunner

  • 14,587 posts
  • Location:United Kingdom

Posted Mon May 6, 2019 11:16 PM

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. :)

#607 rensoup OFFLINE  

rensoup

    Space Invader

  • 26 posts

Posted Wed May 8, 2019 8:29 AM

 

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 :-o  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.

 

 



#608 Nezgar OFFLINE  

Nezgar

    Stargunner

  • 1,963 posts
  • Location:Saskatchewan Canada

Posted Sat May 11, 2019 11:43 PM

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)


#609 phaeron OFFLINE  

phaeron

    River Patroller

  • Topic Starter
  • 2,764 posts
  • Location:Bay Area, CA, USA

Posted Sun May 12, 2019 5:40 PM

Update:
http://www.virtualdu...3.20-test24.zip
http://www.virtualdu...-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.

 

 



#610 Faicuai OFFLINE  

Faicuai

    Stargunner

  • 1,054 posts
  • Location:Florida, U.S.A.

Posted Tue May 14, 2019 10:02 PM

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 ! ;-)



#611 phaeron OFFLINE  

phaeron

    River Patroller

  • Topic Starter
  • 2,764 posts
  • Location:Bay Area, CA, USA

Posted Thu May 16, 2019 12:24 AM

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.



#612 Faicuai OFFLINE  

Faicuai

    Stargunner

  • 1,054 posts
  • Location:Florida, U.S.A.

Posted Thu May 16, 2019 10:37 AM

 

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 by Faicuai, Thu May 16, 2019 11:21 AM.


#613 flashjazzcat ONLINE  

flashjazzcat

    Quadrunner

  • 14,587 posts
  • Location:United Kingdom

Posted Thu May 16, 2019 12:02 PM

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



#614 Faicuai OFFLINE  

Faicuai

    Stargunner

  • 1,054 posts
  • Location:Florida, U.S.A.

Posted Thu May 16, 2019 12:07 PM

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.



#615 phaeron OFFLINE  

phaeron

    River Patroller

  • Topic Starter
  • 2,764 posts
  • Location:Bay Area, CA, USA

Posted Thu May 16, 2019 10:40 PM

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.

 



#616 Nezgar OFFLINE  

Nezgar

    Stargunner

  • 1,963 posts
  • Location:Saskatchewan Canada

Posted Fri May 17, 2019 9:38 AM

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.







Also tagged with one or more of these keywords: altirra, emulation

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users