[Correct way to detect 80-column output is being used?]

21 minutes ago, Rybags said:

Do the software only based 80-col drivers do this also (generally I've never used them myself)

Yes.

 

VBXE for completeness:

 

[Correct way to detect 80-column output is being used?]

1 hour ago, idk said:

What hardware supports 64-columns?

None, I think, but there is a software driver for SpartaDOS X.

 

[Correct way to detect 80-column output is being used?]

Check the value of RMARGN, PEEK(83). 40 columns, RMARGN = 39. 64 columns, RMARGN = 63. 80 columns, RMARGN = 79.

[Altirra 4.20 released]

On 1/20/2024 at 8:10 AM, phaeron said:

CPU: Fixed BRK instruction pushing flags to wrong page in 65C816 mode with relocated stack.

It somehow still does not work correctly, in test2 and test3 I can observe the same behaviour as before, i.e. when BRK is executed, the return address gets written to the actual stack (in my case: $BFF1-$BFF3), but the corresponding status register contents ends up at $01F0.

[Any basics that do better random access files?]

21 hours ago, pcrow said:

Reading a file while it is being written is a problem.

I didn't mean reading a file while it is being written. By "afterwards" I meant "after the file has been entirely written and closed". Before the first closure a file cannot be opened another time.

 

21 hours ago, pcrow said:

What happens now if you open an 8K file for reading, read 4K, open it to append, write 8K, then read to the end.  Will the read stop at the original 8K, or will it catch the update and read the 16K?

Without looking at the code: it will stop the reading at the original 8k (you opened it twice, once for read and once for append, so you have two handles and also two separate descriptors).

 

21 hours ago, pcrow said:

three extra bytes in the directory entry

Hmm, what three extra bytes in the drectory entry?
 

21 hours ago, pcrow said:

how many files have more than 255 sectors

This depends on the sector's size. Plethora of files are longer than 32k (255*128), tons of them - longer than 64k (255*256), quite a lot - longer than 128k (255*512). The real question is - is the percentage of very short files worth all the trouble?

 

21 hours ago, pcrow said:

Multiple files being written at the same time are not a problem, as DOS only deals with one operation at a time.

Yup, you can still easily generate interleaved writes to multiple files "at the same time". Also the more general question is: how many files on a disk frequently written-to are non-fragmented? Looking at my "asm source" partition, there is a ton of files revisited, edited, regenerated from time to time and the fragmentation % is probably rather high. Say, in theory, someone comes and implementes this "contiguous files" feature. What is the gain? Speed? None. Capacity? Sector maps saved, which in the end will have to be written anyways the more the disk gets fragmented. What is the loss? DOS code size/complexity - much added here. A disaster on a floppy drive, when to read a file which begins at a low track it has to seek to a high track again and again, because the system found out that the file can't be contiguous at track 33 and all the sector maps for the file are there.

 

In short, it is, IMHO, much a do about a feature that gives no practical gains. So, to refer to your words above, I do not think that "it would certainly make sense". YMMV.

 

Besides, there is no place in SpartaDOS directory entry for that flag. The only status bit, which was free, has already been allocated (status $4x = symbolic link).

 

[Any basics that do better random access files?]

33 minutes ago, pcrow said:

As to SpartaDOS having a "contiguous file" flag, that would certainly make sense.  If the next sector to be allocated isn't contiguous, it would then allocate two sectors: first the sector map for the file, and then the next sector for data.

Please provide an algorithm flow-chart of writing such a file to the disk. Especially, if after e.g. 1 MB data written it suddenly turns out that the next sector to be written is already allocated to another file and you have to skip it. And how do you detect that situation while reading it afterwards and deal with it.

 

Not to mention that an Atari program can write two (or more) files to a disk simultaneously...

[Chip8 emulator version 1.0]

2 hours ago, pirx said:

I found out that the available docs are pretty vague.

This one too? http://atariki.krap.pl/index.php/Wiersz_poleceń

 

What is missing?

[rapidus - correct sequence of upgrading]

8 hours ago, Piotr D. Kaczorowski said:

Few days ago on Discord Pasiu said:

"Widzę, że fabryka wciąż wrzuca stary wsad flasha do Rapidusa. A prosiłem wieki temu, by uwzględnić poprawkę..."

(ang. I see that the factory is still using the old flash image for Rapidus. I asked ages ago to provide the correction... ).

I am sure he was talking about the part of the flash which is filled with 6502 and 65C816 code (booter, BIOS, OS), not about the FPGA core.

 

8 hours ago, Piotr D. Kaczorowski said:

Is there anything else that can be done to ensure that everything is up-to-date?

Check my page from time to time for (most probably) OS updates

 

[Altirra 4.20 released]

Altirra, when it is minimized under Windows 7, quite often crashes when maximized back. I also observed it before 4.30-test. Crash dump:

 

AltirraCrash.mdmp

[rapidus - correct sequence of upgrading]

54 minutes ago, Piotr D. Kaczorowski said:

I saw the PBI0.ROM files in the packages. Later, I also read that it should be done before any updates. How can I check if anything else needs updating?

You cannot. It is the flasher which in fact should do that, but it does not. You also cannot really update PBI0, it is embedded in the core.

 

But it is actually enough to check the core revision: 054e is the final production core and all actual updates are compatible with it.

[Altirra 4.20 released]

4.30-test1 (but 4.20-test29 had the same issue). In 65C816 emulation, when in native mode, when the stack is relocated outside the page $01, executing BRK causes the return address to be written to the actual stack, but the flag register is written to SP&0x00FF|0x0100:

 

Code:

 

00:0600: 18                CLC
00:0601: FB                XCE
00:0602: A9 80             LDA #$80
00:0604: EB                XBA
00:0605: A9 FF             LDA #$FF
00:0607: 1B                TCS
00:0608: 00                BRK
00:0609: 00                BRK
00:060A: 4C 0A 06          JMP $060A               ;[expand]

 

Console:

 

CPU: Illegal instruction hit: 0609
(14971:201, 78) C=80FF X=--A3 Y=--01 S=80FF P=B1 (N MX   C)  00:0608: 00                BRK
              B=00 D=0000
Altirra> t
(14971:201, 81) C=80FF X=--A3 Y=--01 S=80FB P=B5 (N MX I C)  00:C9DB: DC 5F 02          JML [$025F]  [$00:C0B7] = $40
              B=00 D=0000

 

Stack at $80FB-$80FF:

 

Memory at $01FB-$01FF:

 

 

This causes the subsequent RTI to pull garbage from the $80FC and load it to the flag register, with obvious results.

 

EDIT: is it possible to have a "Stop at NOP instruction" in the CPU options, such as it is now with BRK?

[rapidus - correct sequence of upgrading]

Updating the Rapidus BIOS (module.rom) is a good idea, because the v.1.0 had a problem detecting if the OS was doing a cold restart. In this case some internal variables the BIOS is maintaining have to be reset. This may bite you when using the dedicated 65C816 drivers for SDX (especially 65816.SYS) - after a cold restart they may not load correctly and a power-cycle is needed. Updating to 1.2 fixes this.

 

Also, is it important to check the core revision prior to an attempt at the update. Cores earlier than 054e may be incompatible with these binaries, and the result may be bricking the machine.

[Strange APETIME.COM behavior]

7 hours ago, bf2k+ said:

the old rev C has BIOS 0.8 in it.  Can I use the update utils on your website to update this old one? Or should I leave it alone?

I think that you should update.

[Strange APETIME.COM behavior]

5 hours ago, bf2k+ said:

now to figure out how to read this clock in SpartaDos 3.2G...

You're already reading it, this is why it is "45 minutes fast". APETIME interrogates the time, and IDE+BIOS responds with the current timestamp from its internal clock.

 

You have to adjust the clock via the IDE+ menu, because it evidently is off.

 

Or disable the "APE time" in the IDE+ menu, it then will allow the external APE respond to the inquiry.

 

Or use SDX, which has the proper clock driver built-in.

[ATRFS: Mount ATR files as local directories under Linux or Mac]

1 hour ago, pcrow said:

Reading the spec, the floppy drawer partitions don't have any way to name the floppies, which seems to be a huge shortcoming.

There are two bytes remaining for definition. It can be e.g. a relative number of a sector containing all the required information. Fortunately, it happened to be not really necessary.

 

1 hour ago, pcrow said:

Also, that would be the partition type most likely to use the weird non-512-byte sectors with different packing methods (why not just choose one?).

A specific type of hardware would surely choose one. The APT table information informs you, which packing method was chosen for the media being about to be mounted.

 

1 hour ago, pcrow said:

if I get it to mount SpartaDOS file systems in type 00 partitions, it sounds like I'll have 95% of the use cases

Probably, if the remaining 5% is MyDOS and friends.

[ATRFS: Mount ATR files as local directories under Linux or Mac]

5 hours ago, pcrow said:

I've thrown some stuff in for supporting chunks in a "floppy drawer" partition.  I don't see anything in the spec about naming the separate chunks, and I don't have any examples to work from yet.

I do not think any such partitions exist. If I remember correctly, the APT specification was designed in the ancient times, when HDD interfaces were not able to run ATR images off the file system. Hence I guess the only partition types which can be found in the wild are $00 (DOS partition) and $03 (external DOS partition).

[Sophia 2 demos?]

I tried several times to convince @Simius to implement a hardware 80-column text mode in Sophia. As I understand, though, he is sure that it is not necessary, because the software-driven 80-column mode is good enough being well readable (Sophia display being, undoubtedly, sharp) - despite that it takes up 8 KB of RAM, which in turn causes a ton of compatibility issues again and again, and is slow in comparison with the mode we have in the VBXE.

 

For me this - the hardware, blitter-supported, 80-column text mode - is a big advantage of VBXE over anything else. And yes, I have a CRT monitor with RGB input (so HDMI offered by Sophia is not really so appealing).

 

EDIT. Take a look at the performance of exactly the same program in two cases:

 

1) 80-column in hardware, VBXE:

 

 

(Ignore the sound: the Covox was on during recording and Altirra does not seem to have an ability to separate the Covox from the VBXE, like on the real hardware, hence the noises).

 

2) 80-column in software, GTIA:

 

[Any basics that do better random access files?]

4 hours ago, pcrow said:

Along those lines, I'm also surprised that there was never a simple DOS that only allowed contiguous files. (...) I'm also surprised SpartaDOS doesn't have a "sequential" flag where it skips the sector listing the sectors in the file since the file is sequential.  With that feature, it would only allocate the sector map for a file if the file grew to be non-sequential.

It might probably have been done so to uphold some sort of healty balance between adding much to the code's complexity (and size) for no practical gain, and not doing that.

[Project Veronica (Weronika?)]

Is there a Veronica BASIC version newer than 0.1 from 2015 (17803 bytes)?

 

During tracing some issues in SDX I discovered that this version is loading/saving garbage when LOAD and SAVE keyword are used. I am going to trace that down anyway, but I wonder if there is anything new besides what I have.

 

Thanks!

 

[Covox??]

1 hour ago, Geister said:

an accelerator board with a 65C816 coupled with a 4MB ram board

Why 4 MB only?

 

As for the Covox: whoever does it, make it *detectable*.

[Any basics that do better random access files?]

41 minutes ago, Rybags said:

A sector map would probably be easiest IMO.

You guys keep reinventing SpartaDOS. No need for that, it has already been invented.

[Covox??]

A Covox indeed does require all the CPU time, but that still does not mean that there cannot be some applications for that, such as trackers (Neotracker for example), module players (mentioned, if I am not mistaken) or WAV players (D2D).

 

As for a more intelligent sound card, there is the Soundboard by @candle. Anyone who has the VBXE can transform it into a Soundboard by flashing into it the relevant FPGA core and connecting the video DACs to a sound amplifier.

[Cleanly running a bootable .xex from a TBXL program]

8 minutes ago, OxC0FFEE said:

is it possible to modify a value to load into a more compatible place in memory?

Unfortunately, not. The regular Atari binaries are not easily relocatable.

[What is it with SDX and ED Atari DOS 2.0/2.5 disks?]

On 12/26/2023 at 10:06 PM, phaeron said:

This is a simulation of reading from a Speedy 1050 booting DOS 2 with high speed SIO. You can see that there is very little dead time for the drive as it very quickly transitions from processing Read Sector commands, to reading the next track, and then to processing Read Sector commands again.

There is still a gap of 1 rotation necessary to read the track to the internal buffer. However, if I understand this correctly, the buffer then gets read out by the computer in about 3 rotations. Normally, without the buffering, the US Doubler turbo interleave allows to read an SD track in 5 rotations - so indeed, there is a gain of 1 rotation. The simulation's baudrate is 52 kbps?

 

On 12/26/2023 at 10:06 PM, phaeron said:

The fastest unbuffered drive setup known is a 1450XLD with PBI-based SIO, and in simulation the best it can do is a 2:1 interleave.

One track in two rotations, then, like the Karin Maxi (it is a PBI floppy drive). It is not a very good comparison, though, because after these two rotations the track's data are already in the computer's memory and the transmission is over.

[Cleanly running a bootable .xex from a TBXL program]

1 hour ago, OxC0FFEE said:

I think the underlying issue is that these expect a clean system to boot into, not to be loaded from TBXL;

TBXL 1.5 occupies 5.5k of RAM from $2080 to $3629, when an executable you want to run (no matter by what means) loads to that area, you will get a crash when trying to return to the interpreter.