dmlloyd

Does anyone know of a reference which explains how command-line arguments are passed to ".COM" style XEXes in DOS XL (and presumably SDX as well)? I'm given to understand that both DOSes use a similar mechanism but I can't seem to find any information about how to write an XEX that accepts arguments. I'm near to disassembling .COMs at this point.

This is a project idea we were chatting about on ##Atari today. The basic idea is that we make it possible for PBI devices to take over the system bus to perform DMA transfers at up to 1.7 megabytes per second. This is done by hooking into the way that ANTIC stops the CPU with a small riser board, and connecting /HALT and a new /DMA signal to two currently unused pins on the PBI.

The device protocol would work like this: when a DMA transfer is desired, the device asserts /DMA. Every cycle that starts with /DMA asserted is a DMA cycle for the device *unless* /HALT was asserted before the cycle began, in which case the device has to relinquish to ANTIC. Devices can use the presence of /HALT at a high level during a read of the device's registers to detect whether DMA is present; if not, devices can fall back to programmed I/O.

I whipped up a quick board layout for this; the board is also designed to generate a "clean" phi2 output as well as allowing the use of a W65C02 or W65C816 instead of 6502C. It does not support other 6502s or 65C02s which do not have the /BE input.

 DMA Board.png   6.49K   18 downloads

Thoughts?

I've been having a weird SIO problem that I'm hoping someone might have some insight into.

The symptom of the problem is this. The Atari will attempt to read a sector (or some other SIO operation). There is about a 70% chance that it will succeed, but the other 30% it will sit for the timeout period (a few seconds) and then retry the sector read. I've seen a sector fail to read 3-4 times in a row before it succeeds and then a bunch will succeed in a row.

The aspeqt log looks like this:

[Disk 1] Get status.
[Disk 1] Read sector 1 (128 bytes).
[Disk 1] Read sector 2 (128 bytes).
[Disk 1] Read sector 3 (128 bytes).
[Disk 1] Read sector 4 (128 bytes).
[Disk 1] Read sector 5 (128 bytes).
[Disk 1] Read sector 6 (128 bytes).
[Disk 1] Read sector 7 (128 bytes).
[Disk 1] Read sector 8 (128 bytes).
[Disk 1] Read sector 9 (128 bytes).
[Disk 1] Read sector 10 (128 bytes).
[Disk 1] Read sector 11 (128 bytes).
[Disk 1] Read sector 12 (128 bytes).
[Disk 1] Read sector 13 (128 bytes).
[Disk 1] Read sector 14 (128 bytes). <-- this is the failed command
[Disk 1] Read sector 14 (128 bytes).
[Disk 1] Read sector 15 (128 bytes).
...etc...

So aspeqt isn't noticing a problem; rather the system just isn't seeing the sector come in for some reason.

Here's the history of the problem. It all started when I dropped in a PAL ANTIC for playing some PAL games. At the time I figured the occasional glitch might be due to timing differences so I didn't think anything of it. After a few weeks of not using my system, I received and installed one of mega-hz's stereo boards (in the process I moved my OS ROM IC to the BASIC spot and removed BASIC, because in a 600XL the board doesn't quite fit). I booted up and everything seemed to work great on the first try, *except* that this SIO problem was still there and in fact was quite a bit worse than it was before! Figuring I had banjaxed something (SIO = POKEY = seems like it might have been related to the stereo board install), I tried reverting the upgrade and there was no change - the SIO problem was definitely still there.

I swapped my ANTIC out for the original NTSC one again hoping that this would resolve the issue but it did not. I checked and rechecked the board for broken traces along every path I could find, even tried different POKEYs to no avail. Then I made a quite interesting discovery. If I boot in Aspeqt using the "boot XEX" feature, it consistently works fine (after it loads the initial few sectors containing the boot loader). This is interesting to me because the OS loads sectors at 19200 bps, but the Aspeqt XEX booter uses 57600 bps (I believe) to transmit the XEX data. So maybe the problem is actually in the OS ROM somehow, though I don't see how since it passes self-test which I think does a checksum test. My other thought is that maybe IRQs are not being handled right somehow since (I think) the OS SIO routine is IRQ-driven, whereas high-speed boot loaders aren't?

Anyone have any thoughts about what I should try next? I was thinking about writing a test program pair for the atari and linux which transmits a data stream and checks for problems, and maybe just swapping ICs (SALLY gets a little warm but I think that's her normal behavior).

Topic says it all. I want to replace my 600XL's 16K OS with a programmable flash device. It has to be easily removed or disabled in case I banjax it. I'd like to be able to reflash in-system. Multiple OSes is a nice-to-have, I suppose, but not really essential at all. Flashable BASIC image is also not necessary as I intend to disable the internal BASIC mechanism anyways.

So, is there a common solution that folks use?

When coding stuff which uses the Atari OS, the reference I use is the (apparently quite commonly available) OS Rev. 5 prototype source code, as it covers just about everything in good detail. One major exception of course is the PBI routines, which were removed in this revision. Does anyone have the original source code to this piece of the XL OS in electronic form? There are plenty of articles but there are certain questions which can only be answered by looking at the source code.

The XL OS is a lot of lines of code, and I know some people who have it in print form were talking about scanning it in which sounds like a pretty massive undertaking, but to be perfectly honest we really only need the differences between Rev.5 and the previous versions to be scanned in order to fill this knowledge gap.

And I personally only need the PBI bits - in particular, PBI IRQ handling, Reset handling, the SIO hooks, and the PBI CIO handler.

I am also interested to see if there are differences between XL and XE PBI code.