Jump to content

TomXP411

Super Administrators
  • Posts

    1095
  • Joined

  • Last visited

  • Days Won

    85

Community Answers

  1. TomXP411's post in cc65 not writing to file was marked as the answer   
    Did you mount an SD card when running the emulator? If I recall, the host filesystem can only be used with SAVE and LOAD, not with sequential files and other CMDR-DOS operations.
     
  2. TomXP411's post in codex was marked as the answer   
    Yes, it does, and Mike is aware. I got a response from @mjallison42, and there are more changes coming:
    -- https://github.com/commanderx16/x16-rom/pull/202
  3. TomXP411's post in PETSCII UI and INPUT statement problem was marked as the answer   
    Yeah , that's how INPUT works. It reads text back from the screen. I've made use of that in the past to do make a poor man's file selector: INPUT at the top of the screen, then let the user press RETURN on the file he wants to load. That works great, up until you have more than 25 files in your directory...
    Anyway, I'm with Ed on this one. If you know you have, say, 20 characters of space, then you just need to do a LEFT$(20) and then trim the spaces off the right side. So a loop might look like this:

    100 INPUT A$
    110 N=20 : REM Max length of the string
    120 IF MID$(A$,N,1) = " " AND N>0 THEN N=N-1:GOTO 120
    130 A$=LEFT$(A$,N)
    **EDIT: You'll probably need to check N for zero and return "". I'll leave it to you to figure out that bit of logic.
    Now A$ has just the characters you're interested in. 
    You could also write your own custom input routine... I've done that a few times. 

    100 A$=""
    110 GET K$
    120 IF K$=CHR$(13) THEN 200
    130 IF K$=CHR$(20) AND LEN(A$)>0 THEN A$=LEFT$(A$,LEN(A$)-1)
    140 IF K$>=" " THEN A$=A$+K$
    150 ... plot and re-print your string.
    190 GOTO 110
    200 REM A$ now has your string.

    You can add more stuff to this, like blinking the cursor, but you get the idea. If you want to handle input yourself, you have to handle all of it. So it's probably easier and faster to just filter the junk out.
  4. TomXP411's post in Thanks for the fix! was marked as the answer   
    Thanks. It looks like a lot of the CSS and template files were modified in the making of this site, but as upgrades happened, the new baseline code didn't make its way into the custom templates. So there were CSS classes and portions of the template that were completely missing (as Vincent noted with the mobile stuff.) We still have a way to go before that's all fixed, but hopefully it's better. I'll keep working on it as time allows.
  5. TomXP411's post in Average amount of 6502 instructions per scan line, does my calculation make sense? was marked as the answer   
    It should be more like 50 instructions per scan line.
    Your math is a bit off, because you forgot about the refresh interval, which actually adds up to 525 total lines.
    So let's work up to the correct answer. 
    525 scan lines at 60 frames per second. That's 31500 lines per second. 
    8MHz at 5 ticks per instruction. That's 1.6MIPS
    x = (8M / 5) / (525 * 60)
    x = 1,600,000 / 31500
    x = 50.79
    So if my math is right, you can get roughly 50 instructions per scan line on the Commander X16. 
     
     
  6. TomXP411's post in User profile page layout problem was marked as the answer   
    A bunch of the template CSS had been removed (and it's entirely possible that an update inserted that into the default code after the fact...)
    I re-applied the relevant block of default code, and now the badges are small and tidy at the top:


    If that looks more like what you'd expect, please click the "Mark as solution" to close out this case. 
    Thanks.
     
  7. TomXP411's post in Missing post was marked as the answer   
    Thread closed. 
  8. TomXP411's post in Tapatalk login problem was marked as the answer   
    I'm going to move this as "closed", since it doesn't seem there's enough interest in Tapatalk to spend a lot of time on this. 
  9. TomXP411's post in Is there a way to set the file pointer for file reads ? was marked as the answer   
    Check the DOS reference in the documentation. There is a position command:
    https://github.com/commanderx16/x16-rom/blob/master/dos/README.md
    in Commodore (and therefor Commander) DOS, you control the drive by sending commands on a side channel. So you have to open a second channel on secondary address 15. Send the Position command and then just continue reading from your SEQ file like normal. 
    So you need to open a second file on SA 15, and send P d0 p0 p1 p2 p3
    device is an 8 bit binary value, and p is a 32 bit word, Little Endian 
  10. 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. 
  11. TomXP411's post in Saving to SD wont overwrite. was marked as the answer   
    No.
    SAVE "@:FILENAME.PRG"
     
  12. 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. 
     
     
     
  13. 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. 
     
     
     
     
  14. 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