Jump to content

thorfdbg

Members
  • Posts

    1,134
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

11,411 profile views

thorfdbg's Achievements

Stargunner

Stargunner (7/9)

524

Reputation

  1. Not really. You can certainly detect when DUP.SYS is about to be loaded (DOSVEC, $0a), but that does not help you a lot because it will stomp on top of your memory anyhow, and even if you relocate yourself to the end of DUP, the DUP will use that memory to copy files or disks. Call it what you like - but the Atari DUP was not very wisely designed. For the XL systems, you may attempt to hide your code under the basic ROM or the Os ROM to get out of the way, and only have a minimal jump table in RAM. DUP is not relocatable either, that is, even if you raise MEMLO, it will ignore that and just load on top of whatever was there.
  2. Yes, my 800Xl runs on Os++ and Basic++ (physical, true hardware). It's surprisingly fast.
  3. Yes. Rev.B fixes some operator priorities and forbids combinations like NOT NOT which crashed rev A. They fixed one bug in the memory mover, and introduced another (more fatal) bug in it. Rev.C fixes this bug, but there are plenty others still in it. Download the Basic++ manual from the Atari++ page, there I listed all the defects I have found: http://xl-project.com/downloads.html
  4. Yes, also NEXT and RETURN only take line numbers + line offsets from the stack, and that's even true for Turbo-Basic. It just has a smarter search strategy. Basic++ is smarter and stores an address.
  5. Amiga Basic aka Microsoft Basic also had an "ON TIMER GOSUB" if I recall correctly. However, this being said, it is a non-standard feature and not available on the Atari. The usual way how to address this is to rethink each part of the game logic in elementary steps. "move player", "move enemy" "animate missles", "check hit" and use one subroutine for each of these "small update steps". The entire game engine then iterates through all of these steps one after another, and repeats up to a certain target, e.g. "player hit", "goal reached" etc.
  6. To let BASIC initialize itself, you need to set the Os WarmStartFlag ($08) to 0, and then launch the basic cartridge. Thus: [code] lda #$0 sta $8 jmp ($bffa) [/code] Actually, that goes for pretty much every cartridge. The Warmstart flag indicates that the initialization comes from a cold start, hence memory contents cannot be trusted.
  7. That is DOS dependent and depending on the open mode. On your classical Atari DOS, there is the "open for update mode", which is mode 12, and there you cannot extend the file post its current end. Thus, when an existing file is being updated, and you attempt to extend it beyond its current file end, you receive an "error 136 - EOF". You can extend such files with the open mode 9, then append to the end, but you cannot read in this mode. Again, Dos 2.++ offers mode 13 which is "read, write, extend beyond its end". In this mode, you can read and write, and in case you write beyond its end, the file is extended and does not run into an EOF error. You can also "seek back", and then continue reading, but of course only up to the position where the new (most recent, updated) EOF position is located (and not where the file ended before the file was written to). But, again, this is a 2.++ extension and not what your average Atari DOS would be able to do.
  8. The Dos 2.++ (and it's precursor, 2.XL) that comes with Atari++ does offer bypassing the FMS - then you have raw sector access, but of course no files: 10 OPEN #1,8,128,"D:-" 20 POINT #1,SECTOR,BYTE 30 PRINT #1;"RAW SECTOR I/O" 40 CLOSE #1 The important trick is the 128 as second parameter for open. This makes the entire disk accessible as a "single file" with 128 bytes per sector. Of course, no file names in this mode. Contiguous files means that the sector allocation of the FMS would need to change. Currently, whenever a new sector is needed, it just checks in the VTOC for a free sector, allocates it and uses it. If you would want a contiguous file, it would need to check whether the next sector is available. What do you do if it is not? Fail with "disk full"?
  9. This is not really the issue of Basic, it is the problem of the FMS. Unfortunately, the random access capabilities of Atari DOS are rather "limited" as POINT and NOTE take an absolute sector number and byte offset within a sector, and since files are not necessarily assigned contiguous sector numbers, you cannot reliably compute from a record number the sector and byte offset. With DOS 3 (which is really just FAT in a disguise) you could as it uses byte offsets from the start of the flie as offsets, but it was already too late at this time.
  10. The fun thing is that ABC is actually not really a compiler. The output is just p-code that is (again) interpreted by a 4K runtime package.
  11. To give you a bit more background: The reason is that 2.XL also keeps the drive buffers behind the Os ROM. To make this happen, serial transfer - as it is initiated by the SIO in ROM - needs to be intercepted such that the received bytes can be moved to the drive buffer that sits in a place were SIO (as ROM component) cannot reach them. That, of course, only works if there is actually a serial interrupt coming, and that only works if SIO remains unaffected and the transfer is not bypassing the usual hardware mechanisms. It is quite unlikely that uDos will have a smaller RAM footprint. In 2++, the issue is solved in a slightly different way, with another external component (FMSOVL.SYS).
  12. You just need the right "autorun.sys" that runs a basic program. I believe there should be plenty that could do. The one attached runs a BASIC program "D:START.BAS". runstart.zip
  13. Dos 2.XL is attached (or rather, its system disk with the complete toolchain). But note that this Dos is in so far minimal as it has a minimal RAM footprint on the XL machines (about 163 bytes if I recall), though is a full-fledged DOS that keeps its DOS under the OS ROM. Otherwise, it is a precursor of the Dos 2.++ which is the built-in Dos of the Atari++ emulator and ROM based. Thus, it is no surprise the Dos 2.++ system disk is quite similar, just maintained better. I have not worked on 2.XL since a long time, 2.++ is the "active branch". The drawback is, of course, that you cannot combine it with TurboBasic as Turbo also uses the RAM under the Os. There is a special version for that case (Dos 2.XA) which is feature-wise identical, and very close to the features of Dos 2.++. It requires, however, a 1050 extended density disk drive - formats to 963 sectors, and keeps the "DOS.SYS" in the (otherwise non-reachable) sectors, i.e. every disk it formats is "bootable". It is not suitable for "keeping all files on a single ATR" as it is limited to a single VTOC with a maximum capacity of 963 sectors (as said). dos2xl.zip
  14. Pokey VOLONLY implements a 4-bit DAC per voice, but since Pokey does not have a DMA channel to supply sample data, it is a very CPU intensive process that is mostly used for special effects (such as software voice) and not so much for music.
×
×
  • Create New...