Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

378 Excellent

About thorfdbg

  • Rank

Recent Profile Visitors

10,339 profile views
  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. Unfortunately, not in general, and the results may be very mixed. Some monitors will show a screen, but it may be not aligned, or scrolled out of the bottom of the monitor due to lack of proper synchronization or alignment. Thus, you can get everything between "a perfect picture", "a partial picture, showing only the top-half of the screen" and "no picture at all".
  6. Are you sure? As these cables require that the analog output pins of the DVI connector are utilized. If this is a fully digital device, then nothing will feed the analog output and you need a digital monitor input.
  7. Not really. As stated, LPRINT under a standard Atari Basic and Atari Os ignores the semicolon at its end, so it is "more a bug of the standard setup", really. The issue is that, as stated, Atari Basic does an implicit OPEN #7, then prints, then a CLOSE #7. The latter also flushes the print buffer under the Atari Os as otherwise the printed characters are lost, and flushing the printer buffer implicitly also appends an EOL, as this EOL indicates where the variably-sized printer buffer ends.
  8. Look, if you already require users to run a custom DOS, why not let them run a more useful custom DOS to begin with?
  9. You probably not only need a new DUP.SYS, but also a new DOS.SYS as creating the MEM.SAV is part of the DOS portion, and this now needs to save another memory area. Frankly, I would argue against this approach. It is fragile and will break if the user does not use your modfied DOS - which some won't.
  10. Dos 1.0 and Dos 2.0 did not have a XIO for binary load. The first Dos that provided one was Dos 3.0 by Atari at position XIO 41 (neither 39 nor 40 is correct). Unfortunately, Atari failed to include the same Xio in Dos 2.5 which came later.
  11. atari++ By demand, the above is a atari++ version compiled for Raspian, just the binary. No sound, X11 output. That's just how far I got in 5 minutes. Have fun!
  12. The E: (and S:) handler do not touch APPMEMHI. Applications do (thus its name). The free memory region is between APPMEMHI ($0E,$0F) and MEMTOP ($2E5,$2E6).The region between APPMEMHI and MEMTOP is of course also used by other applications, e.g. the DOS++ "COPY" command, as it is "free memory", or as stack for the TurboBasic FILL command. It is therefore MEMTOP you want to adjust, not APPMEMHI. APPMEMHI is under control of the executing program, e.g. Basic. So if you want to relocate, you need to do so before every graphics mode change, to a region below the new MEMTOP which you would need to compute from the target graphics mode, and then adjust MEMTOP to point below your relocated hander after the screen and/or editor open CIOCMD returns. Thus, doable in principle, the question is just "where to place the relocation function itself".
  13. No, look, this is a documented entry point. It is the last entry in the reserved jump table.
  14. Just checked, no: It still requires to flip the disk. It neither uses the Dos functions for loading, it seems I rather modified the print shop loader to the 2.0 directory and file structure. Sorry, this probably won't help you much.
  15. Err, no. There are several DOSes that adjust LOMEM on every reset, so if you don't, your lowmem will be overwritten.
  • Create New...