Jump to content

thorfdbg

Members
  • Content Count

    940
  • Joined

  • Last visited

Community Reputation

387 Excellent

1 Follower

About thorfdbg

  • Rank
    Dragonstomper

Recent Profile Visitors

10,376 profile views
  1. I continue loading from the same file. everything else would be quite inconvenient. You find example code here: http://www.xl-project.com/download/os++.tar.gz There, look into menuloader.asm which does exactly that. The sources also include a makefile (for ca65 and gcc) and sources to create the relocation information. The relocatable file then consists of "menu.asm" and the "menuloader.asm", plus relocation information. The "reloc.c" file creates the relocation information from two assembled versions of the menu.asm. I would not state that Sparta is universally used. I would rather say that the most widely used DOS is Atari's DOS 2.5. For my taste, the memory footprint of Sparta is too steep. Dos 2.5 does not provide such services.
  2. The way how I do that is to first load a small loader into a "known to be available" space, e.g. page 6, and then the loader figures out where the binary would need to go (e.g. above MemLo), pull in the data from the file, and then relocate through data also in the file. Technically, such a binary consists of a regular "binary load file" in the sense of the regular Atari DOS syntax, whose first chunk sets an init vector, that is, fills the vector at 2E2,2E3. Then, after finding the init vector filled, the Dos loader will jump through the init vector, thus to your program, and from there, you can continue loading. Relocation information is in the simplest case just a bitmask, one bit for each byte in the file, whether it needs to be relocated. In such a simple layout, one would need to round up to entire pages as only the high-bytes would need relocation. In more complicated setups, one would need a table. Yes, of course, memory allocation on such old machines is shady, and there is not much service the operating system has to offer. Atari is in a sense both better and worse than the C64. Better, because there are at least some known pointers the Os uses to allocate and reserve memory (those I mentioned above), worse, because it is necessary to use them as the screen will be relocated, and the size of the DOS will vary, so you better use them.
  3. More needs to be said on memory configuration, allocation and returning. There is still a lot of confusion. Free memory for applications starts at MEMLO, the contents of the pointers at $2e5,$2e6. MEMLO is dynamic, and will depend on the DOS. For some DOS versions (e.g. Dos++) it can be as low as $800, but generally, a value of $1f00 is generally assumed safe. Ideally, binaries should be able to relocate themselves, even though this was rather uncommon at its time. The highest address that can be used by an application is MEMTOP, $2e7,$2e8. Above that the Os uses screen memory. The highest used memory used by the application should be placed in APPMEMHI, $e,$f. Then, when changing the grapics mode, the Os will use between RAMTOP ($6c) and APPMEMHI, and upon successful allocation, adjust MEMTOP. Thus, MEMLO and MEMTOP are adjusted by the Os, APPMEMHI by the application, and memory allocation increments APPMEMHI, releasing memory shrinks APPMEMHI. Memory between MEMLO and APPMEMHI is memory allocated by the application, memory between APPMEMHI and MEMTOP is free and avaliable for the graphics. Graphics memory starts at MEMTOP and exceeds to RAMTOP. Finally, JMP ($0a) does not return from the program. It rather calls to the DOS. This may not exactly what the user wants as it may require loading DUP.SYS from disk, or inserting a disk. In general, an RTS should be preferred.
  4. Note well that the zero-page variables used in your function, and in the "stack handling functions" of the C compiler library are then not available otherwise. In particular, since the stack handling functions are likely used by the main part of the program, and likely require some zero-page variables, this is likely to fail. Interrupts typically mean "assembler only". The 6502 is badly equipped for higher languages that require stack handling.
  5. What you can do is to set the background color of Antic 2, i.e. $d018 to the rainbow color AND $F0, and the foreground color to the rainbow color itself. This will give you the full rainbow on the text, but a (dull and dark) rainbow on the background.
  6. Another day, another luck. Here is a version with a modification of the alsa driver. Strangely, the implementation on the pi does not seem to support some of the alsa calls. atari++.tgz
  7. The only issue I see is that alsa has a hickup, which you can workaround by disabling the sound on the command line, and lots of harmless compiler warnings, but as you wish, here is another release candidate for the 1.84 with hopefully some of the issues addressed. atari++.tgz
  8. If you want better/more scaling options, use the SDL video output, which offers some interesting options for that. The X11 output is very bare bone, but fast even on slow machines.
  9. This looks like the emulator cannot set the target format of the alsa sound output. You may try to disable the sound.
  10. Don't we have Agent U.S.A. already? The only modification required would be a bad yellow hair piece for the fuzz bomb...
  11. There is no general problem with replacing the selftest. Os++ keeps the DUP in this area. However, if the checksum is not correct, it is not the Basic that will be disabled. Instead, it jumps directly to the selftest, as reported. Probably you changed something in the basic area so its checksum or start flag is no longer correct.
  12. Wouldn't do that nowadays. Use an assembler and editor on the host system, e.g. ca65 and emacs. Then test in the emulator. You have all the facilities of the host system, not only an editor, but also a version management system, a powerful command line etc.
  13. Similar problem, command line parsing of the DUP of Dos++, where I had the constraint that everything has to fit into very limited ROM space. The trick is here to transpose the command table: ldx #NumCommands-1 ldy #3 ; command starts now again at the zero offset scanloop: lda CmdChar1,x cmp DupBuffer,y bne nextcmd lda CmdChar2,x cmp DupBuffer+1,y bne nextcmd lda CmdChar3,x cmp DupBuffer+2,y beq foundcmd nextcmd: dex bpl scanloop ;; The command is unknown. Signal this condition lda DupError jmp ReportError ; signal the error repeat2: rts foundcmd: stx DupTmp ; keep the command index jsr FindEndOfToken ; advance to the end of the token. There could be an argument here ... ;;; Commands sorted by character position for easy comparison CmdChar1: .byte "DDRLUCFCRSCLN" CmdChar2: .byte "IEEONAOLUAOOE" CmdChar3: .byte "RLNCLRRENVPAW" NumCommands = *-CmdChar3 Commands are all 3 bytes each, and read (in the above table) top to bottom (not left to right).
  14. As the name suggests, it delays a signal by a given amount of time (a couple of nanoseconds). It is used in the XL series to generate the CAS and RAS signals for the RAM chips. Even though each chip contains 64Kbits, it does not have 16 address pins to address each bit, but only 8 address bits. You first supply the row address, then the column address, as the RAM forms a 2d matrix. The delay between the row and column address is generated by the delay line. These are electro-accoustic modules, i.e. "mechanical" in a sense and thus can die of old age.
  15. That's really due to the way how the PIA ports work. PIA has two ports, port A and port B, where the A side handles the joysticks, and B which handles the MMU (or the joystick on the old machines). The difference is that Port A has a single ended output driver where a single transistor can pull the signal to 0, but there is only a resistor to drive it up to 1. Thus, if there is capacity as load on the line, it takes longer to transition from 0 to 1 than from 1 to 0, and the time depends on the internal resistor. Port B is an active push-pull output, with transistors switching in both directions. Looking back, it would have been better to use Port B for the joysticks and Port A for the MMU, but it is too late to fix that, and it is a historic accident as the A side reads the first two joysticks of the old model which are identical to the joysticks of the XL series.
×
×
  • Create New...