Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Community Answers

  1. TomXP411's post in How does PS2 keyboard interface work was marked as the answer   
    So the thing you’re missing about the keyboard is that the keyboard generates the clock. And since PS/2 is an event driven protocol (messages are sent when a key is pressed or released), the system requires interrupts. 
    So the keyboard and mouse ports will be hooked to the IRQ line, because they have to be.
    So the process would be that when you press a key, the keyboard will cycle the clock line, triggering an interrupt, and the computer will then start reading the clock and data lines. Once the data has been read from the port, the character will be placed in the keyboard buffer. 
    I haven’t looked at the keyboard code in the emulator yet, but it’s possible that the emulator is injecting values directly into the system; that’s the approach I took when I first started my own virtual computer project. 
  2. TomXP411's post in Saving to SD wont overwrite. was marked as the answer   
  3. TomXP411's post in Ask VERA: Why is the character set shifted? was marked as the answer   
    Are you talking about screen codes (used with POKE) vs PETSCII codes (used with PRINT, CHR$, ASC)? 

    Or are you talking about PETSCII vs ASCII?
    The reason the character codes are different than the PETSCII order is reverse characters and control codes. If you look at PETSCII or ASCII, the first 32 values are used for control characters. This would be wasted space if Commodore didn't use those screen codes for something. So they chose to put the screen codes in a different order to make everything fit. 
    I don't know why they put A-Z at the beginning of the character set, rather than using that space for graphic glyphs, however. If I'd been making that decision, I would have kept 32-127 the same and just moved the C= key symbols into 0-31. 
    As to PETSCII vs ASCII... that goes back to the PET. The PET 2001 did not have lower case characters. Instead, Commodore put the line drawing glyphs in the space between 96 and 127. Later, this changed, when the character set was expanded to allow for lower case. But by then, the damage had already been done. BASIC relied on the PETSCII character set staying unchanged, and so that legacy lived on through all of the Commodore 8-bit computers. 
  4. TomXP411's post in Slow map woes (in BASIC) was marked as the answer   
    Here's an example of how to show and fill the second layer:
    10 FOR P=$9F2D TO $9F33:READ A:POKE P,A:NEXT
    20 DATA 96,128, 124, 0, 0, 0, 0,
    30 COLOR 1,0:CLS
    40 C=65:REM "\XC1"
    50 POKE $9F29,$31
    60 PRINT "\X13\X11\X11\X11\X11COLOR 1,6\X13"
    100 FOR Y=0 TO 59:Y0=Y*$100
    105 FOR X=0  TO 158 STEP 2:P=Y0+X
    110 VPOKE 1,P,C:VPOKE 1,P+1,$51
    120 NEXT:NEXT
    The trick is the color: you need to use color 0 on the foreground layer to make the background layer visible. The simple way to make that happen is COLOR 1,0:CLS. This sets the foreground color to white, clears the background color, then clears the text layer. 
    And you can hide the entire background at once with 
    COLOR 1,6:CLS
    Then expose parts of the background with COLOR 1,0 and then printing a block of spaces:
    COLOR 1,0:FOR I=1 TO 9:PRINT TAB(X);"         ":NEXT
    This is a rough example that includes clearing the fog of war as you move across the screen.... 
    10 FOR P=$9F2D TO $9F33:READ A:POKE P,A:NEXT
    20 DATA 96,128, 124, 0, 0, 0, 0,
    30 COLOR 1,0:CLS
    40 C=65:REM "\XC1"
    50 POKE $9F29,$31
    60 PRINT "\X13\X11\X11\X11\X11COLOR 1,6\X13"
    70 IF VPEEK(1,0)=C THEN 200
    100 FOR Y=0 TO 59:Y0=Y*$100
    105 FOR X=0 TO 158 STEP 2:P=Y0+X
    110 VPOKE 1,P,C:VPOKE 1,P+1,$51
    120 NEXT:NEXT
    200 COLOR 1,6:CLS:X=1
    300 PRINT"\X13\X11\X11\X11\X11\X11\X11\X11\X11\X11\X11";
    310 COLOR 1,0
    320 FOR I=1 TO 9
    330 PRINT TAB(X);"         "
    340 NEXT
    350 GET A$:IF A$=""THEN 350
    360 IF X<70 THEN X=X+1:GOTO 300
    400 COLOR 1,6
    Everything up to line 120 is just setting up the background. 
    200 hides the background.
    300-400 clears the fog of war in a 9x9 grid.
    In line 300, we reset the cursor and move it down by a set number of spaces (11, in this case)
    Then in 310, we switch to color 1,0. This exposes the background layer when we draw a space character. 
    320-340 draws 9 rows of spaces. 
    350-360 just waits for a keypress and repeats the cycle. This gives you an idea of the timing of the process. 
  5. TomXP411's post in ISA support was marked as the answer   
    ISA is not really practical. The bus cycles are too different on 8088, and therefore the ISA bus. The 6502 reads and writes memory in a single clock cycle. The ISA bus needs 4 clock cycles to do the same. 
    If you really want to interface ISA devices, you'd need to build an ISA bridge board, like the Amiga had, where the ISA slots sit on their own backplane, and you would have to build some sort of FPGA interface to drive the ISA bus and pass data back and fort between them. Even so, you'll end up with 3 wait states for every ISA transaction. A single 6502 memory operation is actually 4 clock ticks on an ISA bus. In the end, you'd end up basically build a PC on an FPGA (something like AO486) and using GPIO to drive the ISA bus, using the Commander as a terminal. 
    This is how the Amiga Bridge board worked - it was a complete PC on a board, sans storage and video hardware. The bridge board could access video and storage via the Amiga Zorro bus or the ISA sockets built in to the Amiga 2000 motherboard... but the thing is, even when using Amiga storage and video, the Amiga was never more than a terminal and/or disk drive for the PC hardware. 
  • Create New...

Important Information

Please review our Terms of Use