Altirra 4.10 released

[phaeron]

4 hours ago, mirao said:

Nice, two nodes setup works for me.

But unable to get working three nodes. I have exactly the same loop setup as on your screenshots and I use listening on "localhost" on three Altirra instances (ports 9001, 9002 and 9003 on the same real machine where the emulators are running). There is no error in Devices. But MIDI Maze shows me only "This is a slave machine" in all three instances.
Am I missing something?  

I have seen issues before that appeared to have been related to buffered data in the sockets -- you can try doing a cold reset on the nodes in turn to flush the buffered data and see if that allows the nodes to establish the loop. Otherwise, you'd need to check the data flows to see which node is not forwarding data ("lfe siodata" in the debugger).

[mirao]

11 minutes ago, phaeron said:

I have seen issues before that appeared to have been related to buffered data in the sockets -- you can try doing a cold reset on the nodes in turn to flush the buffered data and see if that allows the nodes to establish the loop. Otherwise, you'd need to check the data flows to see which node is not forwarding data ("lfe siodata" in the debugger).

Great. I did a network setup again, this time with a game started after that configuration and now it's working.
So maybe a cold reset could solve the issue and it was only about order of setup and start of game. I think originally I tried only warm reset when a network setup was done.

 

Thank you very much.

[Pixelfetish]

Hello, I have a question and need some help with Altirra.
Basically I want to retrieve a basic listing from a spartaDOS disk.

So I boot the disk in drive d1 and enter load "d1:name.ext"

The listing is loaded and I can run it.

When I want to save the listing on h1: or h6:
error 130 shows up.

When I boot without the disk, H: works perfectly, it is setup correctly.

 

Is H: drive not working with SpartaDOS loaded, in this case X-dos 2.3n?

Seems my knowledge here is somewhat limited.
I have attached the disk.

 

Thanks for any help.

DasGrosseSpieleBuchFuerATARI-D1.atr

Edited May 10, 2023 by Pixelfetish

[phaeron]

1 hour ago, Pixelfetish said:

Is H: drive not working with SpartaDOS loaded, in this case X-dos 2.3n?

DasGrosseSpieleBuchFuerATARI-D1.atr 90.02 kB · 2 downloads

This isn't SpartaDOS, XDOS is a different DOS.

 

XDOS unconditionally stomps the 6th and 7th entries in the CIO device table (HATABS) regardless if anything is there. This not only breaks H:, but will also break any CIO handlers registered by parallel bus interface devices.

 

You can work around it by removing and re-adding the H: device after boot, but I would recommend getting another DOS.

[Pixelfetish]

1 hour ago, phaeron said:

This isn't SpartaDOS, XDOS is a different DOS.

 

XDOS unconditionally stomps the 6th and 7th entries in the CIO device table (HATABS) regardless if anything is there. This not only breaks H:, but will also break any CIO handlers registered by parallel bus interface devices.

 

You can work around it by removing and re-adding the H: device after boot, but I would recommend getting another DOS.

Works. Thank you very much once more. 

[Pixelfetish]

3 hours ago, phaeron said:

XDOS unconditionally stomps the 6th and 7th entries in the CIO device table (HATABS) regardless if anything is there. This not only breaks H:, but will also break any CIO handlers registered by parallel bus interface devices.

 

Just wanted to add a remark....

 

I wrote a short basic program showing the HATABS entries with peek, here is the result.
After re-adding H: drive it appears to be at 032F (815), which is FREE ENTRY 3, the 8th position. Is the entry in HATABS for H: fixed at 032F (815) or does it vary? I think this question was somehow absent in mind.

READY
RUN
MEM:      794       VAL:      80   P
MEM:      797       VAL:      67   C
MEM:      800       VAL:      69   E
MEM:      803       VAL:      83   S
MEM:      806       VAL:      75   K
MEM:      809       VAL:      68   D  ?? dunno about this letter (FREE ENTRY 1 (DOS) according to Mapping the Atari)
MEM:      812       VAL:      77   M  ?? dunno about this letter (FREE ENTRY 2 (850 MODULE) according to Mapping the Atari)
MEM:      815       VAL:      72   H
MEM:      818       VAL:      0
MEM:      821       VAL:      0
MEM:      824       VAL:      0
MEM:      827       VAL:      0

Maybe I understand entry 6 for xdos, but not entry 7, where probably the H: drive was residing.

Edited May 10, 2023 by Pixelfetish

[drac030]

46 minutes ago, Pixelfetish said:

D  ?? dunno about this letter (FREE ENTRY 1 (DOS) according to Mapping the Atari)

D is "D:", i.e. the default disk FMS device. And an entry in HATABS is only "free" when empty ($00). Thus installing anything there should begin with finding an empty slot, then taking it, if one is found. Here we apparently have a case of XDOS not taking into account that there can be any devices besides what the ROM OS installs, and installing itself blindly into a slot, which in certain configurations may be already taken (like by "H:" in emulation, additional devices in custom OS-es or in - already mentioned - PBI handlers).

[phaeron]

3 hours ago, Pixelfetish said:

MEM:      809       VAL:      68   D  ?? dunno about this letter (FREE ENTRY 1 (DOS) according to Mapping the Atari)

MEM:      812       VAL:      77   M  ?? dunno about this letter (FREE ENTRY 2 (850 MODULE) according to Mapping the Atari)

You don't need to dump the handler table from BASIC, Altirra has a debugger command to do this:

 

Altirra> .ciodevs
Device  Handler table address
  P:    $E430 (PRINTV)
  C:    $E440 (CASETV)
  E:    $E400 (EDITRV)
  S:    $E410 (SCRENV)
  K:    $E420 (KEYBDV)
  D:    $13EF
  M:    $13EF

 

As for slots 1 and 2, if you got that from this program listing:

https://www.atariarchives.org/dere/displayfile.php?file=chapter8/CH8PRG3.SRC

 

...I'm afraid that Mapping the Atari is wrong here, those slots are not associated with DOS and the 850. Both DOS 2 and the 850 handler register in HATABS the right way, by finding the first unused entry. If you have a system with the stock OS and no PBI devices and boot DOS 2.0S/2.5 with an 850 connected, then you will get D: in the 6th slot and R: in the 7th slot, because DOS will boot first and then its AUTORUN.SYS will load the R: handler from the 850. But if you boot the 850 without disk drives then you will get R: in the 6th slot, or if you have R: from a PBI device then R: will be before D:, etc.

 

Altirra uses the same strategy when registering its devices -- it will register H:, B:, or whatever on the first free entries in HATABS on boot or whenever you add the device, whichever is later. Things are a bit trickier on removal if the emulator needs to remove a device from the middle of the list -- in that case it will move items from the back and fix up any open IOCBs, and delay removing any devices that are still open. Most of the time that works out, but best not to do it when file I/O is going on. Or pretend that you're on real hardware and not hot-plug devices. 😁

 

As for the slot that H: ends up in when you use the workaround, that's because XDOS registers two devices, D: and M:. I have no idea what M: does.

 

[Teapot]

I'm trying to use standard CIO calls to get a directory listing and it looks like the H: device returns an error code of 3 when returning the final "xxx FREE SECTORS" record. The same line from a D: device returns 1 as expected (SUCCES).

 

They both return a proper EOF on the next read.

 

This is true in Altirra 3.20 (I'm lazy about updating) and also 4.20-test12 (ok, maybe not that lazy).

 

I'm working in Assembler but here's a BASIC demonstration:

 

10 DIM A$(20)
20 OPEN #1,6,0,"H:*.*"
30 INPUT #1,A$
40 PRINT A$,PEEK(851)
50 GOTO 30

 

[flashjazzcat]

Well, I know that MYDOS returns code 3 (more of a status than an error, since bit 7 isn't set) after reading the last character of a file (the next read after that returning EOF), and I assume DOS 2.5 does as well since the behaviour was regarded as canonical enough to build into a recent version of the SpartaDOS X AtariDOS driver as a compatibility fix (my own DOS behaves like this too).

 

Which DOS are you using which doesn't exhibit this behaviour?

 

Edited May 14, 2023 by flashjazzcat

[Ricky Spanish]

34 minutes ago, flashjazzcat said:

I assume DOS 2.5 does as well

Yes Sir. Error - 136.

[phaeron]

In testing, DOS 2.0S and SpartaDOS X don't seem to return the EOF-success code for directories like they do for files. Not surprising since it's not the only case where directory reads are special.

 

[flashjazzcat]

Yeah. I suggested this to Konrad years ago because I believed it to be the reason AMAC wouldn't run under SDX (I felt it expected code 3 after reading the last character of the source file), but I can't imagine any software which would rely on it being implemented for directories. My FMS returns the EOF-success code on a 'raw' directory (which ATARIDOS.SYS might too; I don't know), but quite possibily fails to do the same with a formatted directory. Not that it makes a hapeth of difference in that context with any existing software, I expect.

Edited May 14, 2023 by flashjazzcat

[Teapot]

I boot an empty DOS 2.5 disk as D1: and have H: pointing at the directory where I build my XEX.

 

Running the BASIC directory test on a real 800XL:

DOS 2.5 (via FN) returns 1.

Sparta 3.2d (via FN) returns 1.

SDX 4.49e (via U1MB) returns 1.

DOS XL 2.30p (via 1050) returns 1.

DOS 2.0s (via 1050) returns 1.

 

That's all I have handy.

 

[flashjazzcat]

As Avery pointed out earlier, few bother to return EOF-success (3) when reading directories, even if they do so for regular files. Altirra's host device is being internally consistent by applying the same methodology to the formatted directory.

 

Since EOF-success isn't an error state, however, you can completely ignore it and just assume any status <128 = success.

 

 

[Teapot]

Yeah, I'll switch my test.

 

It brings up the question of whether it's better for H: to be internally consistent or consistent with other devices.

 

It's too bad it isn't 3 everywhere. It would be a convenient marker of the free sectors line so I could ignore it more simply.

[flashjazzcat]

2 hours ago, Teapot said:

It brings up the question of whether it's better for H: to be internally consistent or consistent with other devices.

It does, although since reliance on the the EOF indicator appears to be vanishingly rare and there's otherwise no reason for software to care what status value is returned as long as it's not a negative number, it's not much of an issue.

2 hours ago, Teapot said:

It's too bad it isn't 3 everywhere. It would be a convenient marker of the free sectors line so I could ignore it more simply.

A common and universally reliable method is to simply check whether the ASCII value of the first character in the returned string is greater than or equal to 48, since the free sectors line is the only entry which will satisfy that condition.

[Teapot]

14 minutes ago, flashjazzcat said:

A common and universally reliable method is to simply check whether the ASCII value of the first character in the returned string is greater than or equal to 48, since the free sectors line is the only entry which will satisfy that condition.

Good to know. I didn't know if the sector count was reliably leading zeros (trying to not get bogged down in config testing at this stage) so I check for the 'S' at the end. Now I wonder if that text ever got localized.

 

[flashjazzcat]

4 hours ago, Teapot said:

I didn't know if the sector count was reliably leading zeros

it isn't, but it doesn't matter.

[drac030]

If I had left a debugger window, say the "Memory 1" window, on a second monitor while last time closing the emulator, how do I call that window back to the main desktop screen, if that second monitor has been disconnected and is currently unavailable?

[Pixelfetish]

1 hour ago, drac030 said:

If I had left a debugger window, say the "Memory 1" window, on a second monitor while last time closing the emulator, how do I call that window back to the main desktop screen, if that second monitor has been disconnected and is currently unavailable?

Isn't it Shift+Windows+Cursor left or right? Moves the active window from one screen to another.

[drac030]

Just tried it:

 

I) run Altirra

II) wait for startup

III) F8

IV) Debug->Window->Memory->Memory 1 *click*

V) Shift+Windows+Cursor left

VI) nothing happens

VII) Shift+Windows+Cursor right

VIII) nothing happens

 

[reifsnyderb]

Where is the Altirra OS source specifically located in the Altirra source code archive file?  I've been all through it and, while BASIC is obvious, I can't find it.  Thanks!

[dmsc]

Hi!

24 minutes ago, reifsnyderb said:

Where is the Altirra OS source specifically located in the Altirra source code archive file?  I've been all through it and, while BASIC is obvious, I can't find it.  Thanks!

 

It is the src/Kernel/source/Shared folder inside the archive.

 

I have a repository with the kernel source history (from 3.11 onward) - extracted from the Altirra sources - here: https://github.com/dmsc/atkernel

 

Have Fun!

[reifsnyderb]

5 minutes ago, dmsc said:

Hi!

 

It is the src/Kernel/source/Shared folder inside the archive.

 

I have a repository with the kernel source history (from 3.11 onward) - extracted from the Altirra sources - here: https://github.com/dmsc/atkernel

 

Have Fun!

Thanks!  I'd been through that folder a couple times but never thought to check the "Shared" folder.  I see it now.   🙂

 

Edit to add:  I just checked out your github.  That may work even better.  Thanks again!

 

 

Edited May 18, 2023 by reifsnyderb