Altirra 4.20 released

[Tim Stone]

14 hours ago, phaeron said:

This sounds like the Atari 1027. It's tougher to emulate this faithfully due to the formed letters, which are more difficult to replicate than just dot matrix patterns, which at worst can be reconstructed by eyeballing. But apparently a much more critical issue is that just about all 1027 print heads have disintegrated due to age, so it's hard to find a reference for the original letter shapes.

Okay, what about some scanned in documents that were printed with it?  or some typewriter typeface?  We all like it to be accurate, but... I do think it was the 1027 though. I loved that little printer back in the day.

[+DjayBee]

21 minutes ago, Tim Stone said:

Okay, what about some scanned in documents that were printed with it?  or some typewriter typeface?  We all like it to be accurate, but... I do think it was the 1027 though. I loved that little printer back in the day.

Did you try if FujiNet PC can print to PDFs?

https://forums.atariage.com/topic/358862-altirra-420-released/?do=findComment&comment=5525095

 

If it does, you can connect it to Altirra and print to it from the emulation.

 

If you work on real hardware you sure can print to a real FujiNet in hardware, then download the PDF to your PC and print it from there to any printer supported by Windows/Mac/Linux.

 

It supports 1027 and 1020 among several others.

 

https://github.com/FujiNetWIFI/fujinet-firmware/wiki/About-Each-Printer

[drpeter]

5 hours ago, DjayBee said:

It supports 1027 and 1020 among several others.

@phaeron it sounds as if the Fujinet guys may have already successfully grappled with these problems?

[Tim Stone]

5 hours ago, DjayBee said:

Did you try if FujiNet PC can print to PDFs?

https://forums.atariage.com/topic/358862-altirra-420-released/?do=findComment&comment=5525095

 

If it does, you can connect it to Altirra and print to it from the emulation.

 

If you work on real hardware you sure can print to a real FujiNet in hardware, then download the PDF to your PC and print it from there to any printer supported by Windows/Mac/Linux.

 

It supports 1027 and 1020 among several others.

 

https://github.com/FujiNetWIFI/fujinet-firmware/wiki/About-Each-Printer

I will check this out, but it does appear he is already working on the PDF stuff.  I like to have the feature built in the emulator as there might be use cases that this might work better. This is very interesting with the 1027.

[phaeron]

On 9/7/2024 at 11:25 AM, Tim Stone said:

Okay, what about some scanned in documents that were printed with it?  or some typewriter typeface?  We all like it to be accurate, but... I do think it was the 1027 though. I loved that little printer back in the day.

Well, the question is whether it's worth emulating the 1027 if a lot of things are missing. Without a controller model, timing and sound emulation is already not possible. Beyond that, the 1027 doesn't actually do that much special, so without the accurate character set, all that's really left is... international characters and underlining.

 

As a side note, the 1027 also has one of the least detailed owner's manuals of any Atari printer.

 

[Tim Stone]

6 hours ago, phaeron said:

Well, the question is whether it's worth emulating the 1027 if a lot of things are missing. Without a controller model, timing and sound emulation is already not possible. Beyond that, the 1027 doesn't actually do that much special, so without the accurate character set, all that's really left is... international characters and underlining.

 

As a side note, the 1027 also has one of the least detailed owner's manuals of any Atari printer.

 

Yeah, I downloaded it a few days ago and I noticed the same thing.  It's very plug n play and data cable plugging it in and printing.  I was mainly thinking of a typewriter style as different than dot matrix.

I did love my Star Micronics NX-10 Printer, sure dot matrix, but I loved that thing.  Printed a banner with Print Shop in 1987. 

 

I never had that color plotter though and use language Logo with it (Turtle programming).  That would be a cool hattrick and so rad.  Would love to see that one. 

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.30-test22.zip
https://www.virtualdub.org/beta/Altirra-4.30-test22-src.7z

• Implemented port translation setting for the generic Printer (P:) device when its printer port is connected.
• Fixed bug where internal BASIC could be enabled on the 1200XL.
• Fixed bug with ATX double density images where the DRQ bit would get left on sectors.
• ATX double density support is now enabled by default.
• PDF printer output is now optimized using custom TrueType fonts.

The PDF printer output now works by embedding a dynamically generated TrueType font with combinations of dot columns and rendering bands using the text primitives. It turns out that this is both massively more efficient to encode in the PDF and faster to render compared to using the vector graphic primitives. The downside is that PDF's character set encoding mechanism is horrific and arguably broken. Also, Acrobat Reader will let you copy the "text" even though it's gibberish.

 

[woj]

Avery, I have huge problems booting / loading CAS files with Altirra OS (3.41 from the latest test build, but the earlier one 3.20 from U1MB installation was more or less the same). The problems occur both in Altirra and on the actual Atari, I tried 3 different files (Black Lamp, Karateka, and my own Popeye). On Altirra it seems that any INITAD block that the loader may have (if that's how the game is indeed loaded or whatever is the game's equivalent) are ignored, for example, Black Lamp goes until the end of the tape seemingly loading blocks, but no splash screens appear (but the screen does get black at some point), and the game does not start. Similarly with Karateka, though the very first splash screen did appear, but the game did not start after loading. For my own game I know the format for sure, INITAD blocks are simply ignored regardless of what the loader is trying to do (in this case it is LKAvalon's loader from xex2cas). On the actual computer (I wanted to test it with my SIO device under development) I get more or less the same results, with the exception that rather than experiencing this "empty" loading (it did happen at least once) I mostly get BOOT ERROR after 2 or so blocks. Two of the offending CAS files attached for reference, they both work fine with the stock OS both in emulation and on my Atari. I am getting an impression that this is some kind of regression problem that happened at some point  (Or I did something stupid, like leaving mounted cart, but I am so far almost certain I did not). 

 

Black Lamp.cas Karateka.cas

[phaeron]

8 hours ago, woj said:

Avery, I have huge problems booting / loading CAS files with Altirra OS (3.41 from the latest test build, but the earlier one 3.20 from U1MB installation was more or less the same). The problems occur both in Altirra and on the actual Atari, I tried 3 different files (Black Lamp, Karateka, and my own Popeye). On Altirra it seems that any INITAD block that the loader may have (if that's how the game is indeed loaded or whatever is the game's equivalent) are ignored, for example, Black Lamp goes until the end of the tape seemingly loading blocks, but no splash screens appear (but the screen does get black at some point), and the game does not start.

It's not INITAD -- that's a function of the loader, as init/run segments are implemented in DOS or loader. The OS cassette routines only understand a raw sequential block load.

 

The issue is more subtle. These loaders open the cassette (C) device with AUX1=5 and expect it to automatically skip the wait for key after the bell tone. The reason this works is due to an undocumented behavior in the OS. Despite the OS Manual saying that K: has no device specific bits in AUX1 and AUX2, it actually implements the forced read bit (AUX1 bit 0) that is documented for the E: device by returning an EOL from the K: GET BYTE handler. This carries over to the C device when it calls the K: device to wait for a key. Thus, the "press play on tape" bell sounds, and then the next tape section load immediately starts. You can see this same behavior in BASIC if you open the C or K devices with AUX1=5.

 

AltirraOS implements the documented behavior, so it ignores AUX1 bit 0 when C is opened and waits for a key press instead. You can still get it to load if you manually press a key quickly enough on each load section, and the accelerated C device option will also bypass it since it also skips the bell. It's not hard to emulate this behavior on K:, so I can get that in for next release.

 

[woj]

Yes, that was indeed it, thought it would be something simple. The LKAvalon loader though still refuses to work, it does not have this AUX1 thing in it I believe, but it is know for some other trickery stuff, something to do with the terminating block. But since I am not married to it, I simply replaced it with the TSCBL loader and that solved the issue.

[woj]

Unfortunately there is more to it. This BOOT ERROR I was getting on the real Atari came back, and I did not change anything on my device's emulation. This is really weird, this morning I was able to completely load Black Lamp by pushing keys through on my NTSC 800XL with AltirraOS 3.41. But I re-approached it now with updated Popeye CAS file - this crashed with BOOT ERROR after two blocks (not even the full loader), the same happened with Black Lamp (and I had it a lot yesterday). So I fully changed the machines and setup - moved to my PAL 130XE and used AVGCart's SIO instead. Same thing, both Black Lamp and Popeye stop after just two blocks with BOOT ERROR. There is a marginal chance that it has something to do with U1MB settings that overlap on both machines, or the fact that both machines use PokeyMAX 4 (this last part I won't be able to check quickly). So it seems that the fact that I was able to load anything CAS with AltirraOS was more of luck than anything else. Something along the lines of the VBI bug? (But I am quite sure one of the reasons of having Altirra OS was to weed out this one). In any case, if you need further diagnosis, run / load something particular, just let me know.

 

Forgot to say, for clarity, with the stock OS and otherwise the same identical setups everything loads just fine (modulo the regular occassional VBI bug related failure mid load, both files are over 50K in size). 

Edited September 17 by woj

[baktra]

1 hour ago, woj said:

Unfortunately there is more to it. This BOOT ERROR I was getting on the real Atari came back, and I did not change anything on my device's emulation. This is really weird, this morning I was able to completely load Black Lamp by pushing keys through on my NTSC 800XL with AltirraOS 3.41. But I re-approached it now with updated Popeye CAS file - this crashed with BOOT ERROR after two blocks (not even the full loader), the same happened with Black Lamp (and I had it a lot yesterday). So I fully changed the machines and setup - moved to my PAL 130XE and used AVGCart's SIO instead. Same thing, both Black Lamp and Popeye stop after just two blocks with BOOT ERROR. There is a marginal chance that it has something to do with U1MB settings that overlap on both machines, or the fact that both machines use PokeyMAX 4 (this last part I won't be able to check quickly). So it seems that the fact that I was able to load anything CAS with AltirraOS was more of luck than anything else. Something along the lines of the VBI bug? (But I am quite sure one of the reasons of having Altirra OS was to weed out this one). In any case, if you need further diagnosis, run / load something particular, just let me know.

 

Forgot to say, for clarity, with the stock OS and otherwise the same identical setups everything loads just fine (modulo the regular occassional VBI bug related failure mid load, both files are over 50K in size). 

I would say, you will need to accept that some software will never work with AltirraOS, because AltirraOS is not the same as Atari OS.

• Illegal OS jumps. Either deliberate or accidental, but not easily discoverable at times when there were no emulators with verifier
• Copying OS ROM to RAM and patching it.
• Assuming some code and data is at specific location in ROM (similar to illegal OS jumps)
• Depending on undocumented, but observed behavior. Sometimes accidental, sometimes deliberate (to save few bytes/cycles). For example, the TSCBL loader, to save one block, has data in the EOF block that should be empty, but it assumes the data will appear in the cassette buffer.

This is all not the fault of the .CAS files, but the fault of the software the .CAS files hold inside.

On top of that, .CAS files that are around can be defective and can work by pure coincidence.

[woj]

17 minutes ago, baktra said:

This is all not the fault of the .CAS files, but the fault of the software the .CAS files hold inside.

On top of that, .CAS files that are around can be defective and can work by pure coincidence.

Yes,  but (a) these particular CAS files do work in emulation with AltirraOS, (b) did work at least once on the real thing with AltirraOS. So it is definitely not about OS compatibility as such. Otherwise I am fully ready to accept reality, reporting this only in case this is a bug in AltirraOS trying to help Avery in making the thing better 😉

Edited September 17 by woj

[woj]

5 hours ago, woj said:

or the fact that both machines use PokeyMAX 4 (this last part I won't be able to check quickly)

The 130XE was much easier to open and I dug up my standard stereo Pokey board. What do you know, it solved the issue! So I should redirect this problem to @foft - short version of the story, PokeyMAX 4 does not play nice loading tapes with AltirraOS, on rare ocassions it does work, but mostly it crashes after 2-3 blocks. (I am with the first version of the PokeyMax4 core, I have not tried your latest Alphas). 

 

(Another side finding was that I had partly damaged image of Altirra OS 3.41, saving the ROM from Altirra is not sufficient, the stuff residing under the registers does not get saved and the nice Amiga like insert floppy animation does not work).

[foft]

1 hour ago, woj said:

The 130XE was much easier to open and I dug up my standard stereo Pokey board. What do you know, it solved the issue! So I should redirect this problem to @foft - short version of the story, PokeyMAX 4 does not play nice loading tapes with AltirraOS, on rare ocassions it does work, but mostly it crashes after 2-3 blocks. (I am with the first version of the PokeyMax4 core, I have not tried your latest Alphas).

Do you have any more info on this? e.g. a register isn't behaving properly, there is a delay to such and such etc?

[phaeron]

I have a suspicion of what might be going on, based on looking at the VHDL. @woj can you try this version with the PokeyMAX 4 and see if it changes the behavior? If I'm right, this has to do with what specific serial port functions are reset by SKCTL bits 0-1 vs. 4-6.

 

This version also implements forced read for K:, so the original set of tapes should now work.

 

AltirraOS-3.43.zip

[woj]

4 hours ago, phaeron said:

I have a suspicion of what might be going on, based on looking at the VHDL. @woj can you try this version with the PokeyMAX 4 and see if it changes the behavior? If I'm right, this has to do with what specific serial port functions are reset by SKCTL bits 0-1 vs. 4-6.

With this version of AltirraOS, this morning before work I was able to fully load Popeye (TSCBL loader) on the PokeyMax4 NTSC 800XL using my Pico SIO device, and I was able to load Black Lamp on the PokeyMax4 PAL 130XE using AVGCart with no key press interventions, not to completion (had to leave for work), but sufficiently far to conclude that it is working. I will do more tests, but it seems this is fixed, both tests went OK on the first attempt. The only thing I still do not understand if that's something to be fixed in PokeyMax4 @foft, or is it that software, including AltirraOS, needs to be more PokeyMaxX aware? 

 

In any case, many thanks! And I am happy I could contribute to fixing yet another "hidden" problem. 

[foft]

I should fix it in pokeymax, it sounds like @phaeron figured out what I did wrong in the vhdl - many thanks again!

[phaeron]

7 hours ago, woj said:

The only thing I still do not understand if that's something to be fixed in PokeyMax4 @foft, or is it that software, including AltirraOS, needs to be more PokeyMaxX aware?

It looks like an issue in PokeyMAX since it acts differently from POKEY, but I'll push the change in AltirraOS as well as there's no reason not to clear bits 4-6. I omitted it because it has no effect with POKEY in asynchronous receive mode, but the stock OS clears it, and there's no problem in doing so.

 

6 hours ago, foft said:

I should fix it in pokeymax, it sounds like @phaeron figured out what I did wrong in the vhdl - many thanks again!

So it looks like the specific issue is that PokeyMAX is resetting the serial input state machine on SKCTL bits 4-6 (serial port mode) instead of bits 0-1 (init). AFAIK, clearing bits 4-6 only resets the serial clock divider flip flops, which is a no-op for asynchronous receive mode since that holds the ch.4 divider in preset anyway while waiting for a start bit. Init mode is what clears the shift state machines, with the exception of the serial port output bit -- there is a warning in the Hardware Manual about needing to output a byte to reset that high, which the OS does on startup.

 

[woj]

I tested more files and they all worked fine.

[ijor]

11 hours ago, phaeron said:

So it looks like the specific issue is that PokeyMAX is resetting the serial input state machine on SKCTL bits 4-6 (serial port mode) instead of bits 0-1 (init). AFAIK, clearing bits 4-6 only resets the serial clock divider flip flops, which is a no-op for asynchronous receive mode since that holds the ch.4 divider in preset anyway while waiting for a start bit. Init mode is what clears the shift state machines ...

 

That is correct. Init, and only Init, is, for most purposes, equivalent to a hardware Reset. As you can see at the schematics, the Init signal is the result of a NOR with SKCTL bits 0 & 1. Wll be asserted only when both bits are zero.

 

Quote

... with the exception of the serial port output bit -- there is a warning in the Hardware Manual about needing to output a byte to reset that high, which the OS does on startup.

Also Right. The serial output port state would be non deterministic on power on, even after "INIT mode", which is probably a chip buglet. After any other reset, it would keep the previous state, which would normally, but not always, be high.

[foft]

So the ‘serial port reset’ on page 99 of the altirra hardware reference manual looks like what I read, although it says bits 3-5 and I did 4-6 thinking that is the clock selection bits. What part of the serial port does writing here actually reset?

Edited September 19 by foft

[phaeron]

8 hours ago, foft said:

So the ‘serial port reset’ on page 99 of the altirra hardware reference manual looks like what I read, although it says bits 3-5 and I did 4-6 thinking that is the clock selection bits. What part of the serial port does writing here actually reset?

That's wrong, I'll remove that. There's a section farther down in the serial port specific section that is more explicit about what is reset.

[foft]

11 minutes ago, phaeron said:

That's wrong, I'll remove that. There's a section farther down in the serial port specific section that is more explicit about what is reset.

Awesome, I'll have a read of that.

 

Many thanks again for your amazing work on the hardware manual and of course Altirra.

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.30-test23.zip
https://www.virtualdub.org/beta/Altirra-4.30-test23-src.7z

• Fix 1025 left margin in short line mode (64 columns).
• Fix device binding weirdness with the 850 parallel port.
• AltirraOS 3.43: SKCTL cassette adjustment for PokeyMAX 4, C/K device forced read (this is the same as 3.43 above).
• 8048 emulator now executes a NOP for $01 to allow the Polish 1029 firmware to run, which has an apparent corrupted byte at location 0.

I'm trying to derive a Unicode mapping for the 1029 Polish version, but the glyphs are kind of hard to read. Plain characters in a 5x7 matrix are tight enough, accented characters are worse:

 

I attempted to decode them based on cross-referencing with the Polish ATASCII chart on atariki since the character set appears to be the same:

 

ŹąźćŚęöÖ£üߣłŃńóÓѴĘśäÜĆĄŻÄż

 

...but would appreciate it if any Polish speakers could point out if they spot any mappings that are incorrect. Ѵ is the one I'm least sure about as it visually differs the most between the printer and computer font and seems most out of place, and I had to dig even beyond extended Latin-1 to find it.