Jump to content

TomXP411

Members
  • Content Count

    178
  • Joined

  • Last visited

  • Days Won

    1

TomXP411 last won the day on June 27

TomXP411 had the most liked content!

Community Reputation

112 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Microsoft BASIC 2 never shipped for any platform that could make use of a CD-ROM or an ISO file. If you want the special Commodore (aka PETSCII) characters, the most reliable way to get them is to use VICE, a Commodore emulator. This is the main download site for the Windows version. Get the "Download zip no-cpuhist" version. https://vice.pokefinder.org/ And you can get other versions here: https://vice-emu.sourceforge.io/ You might also look at the TheC64 or TheC64 Mini, which are stand-alone computers running the Commodore 64 and VIC-20 environments. The full size TheC64, with built in keyboard, is releasing in the US in November, here: https://www.amazon.com/C64-not-machine-specific/dp/B08GMTJYXJ/ref=sr_1_3?dchild=1&keywords=thec64&qid=1600880449&sr=8-3 and is already available in other parts of the world.
  2. it's because binary numbers... there is no even binary number for decimal 80, and color data is packed with character data. So the simplest way to address a line in VERA is in multiples of 256. This also makes it super easy to address a character cell: $9f20 selects the column and $9F21 selects the row.
  3. VERA has two data ports, DATA0 and DATA1. You can read and write to either of these ports, and they can be set to different addresses. So copying video memory is a matter of setting one port to your read address and one to your write address, setting the correct Increment value for each, then simply reading and writing n times. To set DATA1 to your read address: Set $9F25 to 1 Set $9F20-$9F21 to your start address Set $9F22 bits 4-7 to your desired increment (2 to move data horizontally. 9 to move it vertically) Set $9F22 bit 3 to 1 when moving text right or down and 0 when moving text up or left. Then set DATA0 to your write address: Set $9F25 to 0 Set $9F20-$9F21 to your write address. Set $9F22 bits 4-7 to your desired increment (2 to move data horizontally. 9 to move it vertically) Set $9F22 bit 3 to 1 to move the text right or down. Then you can just read from 1 and write to 0. Why do DATA1 first? I like to leave VERA in the state where DATA0 is active. I'm betting most people won't bother to set ADDRSEL, so there could be cases where something writes to the screen without checking ADDRSEL first and then writes using the wrong register. So always reset ADDRSEL to 0 after setting ADDR1. Also, don't forget that the screen buffer is actually 128 columns wide and 64K (256 lines) tall, so you can put a lot of stuff in memory outside of the visible space, then scroll by manipulating the HSCROLL and MAPBASE registers.
  4. Welll, I used to play MODs on my 8MHz PC... so the Commander should totally be able to do it, even if it's cheating by manipulating the volume register directly. I was under the impression there would be a way to play PCM audio, but I may have misunderstood what the PSG was.
  5. Yup. Greg nailed it. The key is that when you use LOAD inside of a running program, variables do not get cleared. So you can use a variable to store "what do I do next?" It works fine with the LOAD command in the program. You just have to follow certain rules.... For example: Program1 10 A$="HELLO" 20 LOAD "PROGRAM2",8 30 PRINT "PROGRAM1" Program2 10 PRINT A$ 20 PRINT "PROGRAM2" If you save those as PROGRAM1 and PROGRAM2, then run PROGRAM1, it will set A$, then load and run PROGRAM2, printing HELLO PROGRAM2 on the screen.
  6. Hmm that's different to my understanding. Let me check into that a little. The letter keys work fine, but the graphic symbols don't map out correctly. This is partly a VICE limitation, since you simply can't represent certain combinations of characters when remapping keys. for example, the [ and ] keys cannot be made to work as [ and ] while also printing the graphic symbols, because [ and ] are already shifted characters. This is a limitation in VICE that I have not been able to work around.
  7. I'm not sure what the issue is... are you trying to get PETSCII characters in a native Windows app, or in the emulator? The keyboard is actually a standard Windows keyboard - so it needs no driver support. If you press the ~ key on your PC keyboard while running the emulator, you'll get the left arrow. Shift that and you get the Pi symbol. Now if you want to get PETSCII in a Windows program, you need to do the PETSCII to ASCII translation in your program. To get started, you should download the C64 font by Style, here: https://style64.org/petscii/ Then look at the PETSCII mapping and figure out how you want your program to store text. The most common way is to use a PETSCII byte stream, then translate the code in the display layer to look like PETSCII glyphs. The simple way to do this is to add $E0 to each character when you draw it on the screen. You'll still need to do some translation and custom keyboard handling, though: the C= glyphs on the keyboard all need to be handled through a Win key chord, and those characters are not in the same order as the letters they live under. (C= A and C= E are actually next to each other in PETSCII, which makes no sense looking at the keyboard. But it does make sense looking at a PET keyboard...) So you'll need to address this with a translation table in your editor. Which you'll have to build. Or you can write a text editor for the CX16 and run it in the emulator. That's what I'm planning on doing.
  8. It's not quite compatible with either of the default keymaps. The Pi key, [, ], and \ keys, RunStop , and Restore keys are all different. (I like that there's a separate ESC and Run/Stop key. I wish the emulator would be updated with these keys.) Do you have a VICE keymap that works with these keys?
  9. That makes sense, and it's a really good idea. The 1541 Ultimate allows you to FTP files in while the system is running, and that's very convenient. However, what I'd probably do is, rather than make the device a disk drive, have it access the SD card through the system bus. Once you've grabbed the DMA pin, you can access the SD card just like the CPU, so if you were to open a file and push your data over to SD, there are zero drivers needed on the Commander. Everything would be self-contained in your network interface.
  10. The keyboard is simply a USB and PS/2 keyboard. You just plug it in to a PC and run the emulator, no special drivers needed.
  11. On a 512K system, you have 63 banks of memory available, with 8192 bytes in each bank. Star Trek typically has an 8x8 quadrant grid, with 64 8x8 sectors. So what you'd do is transfer data into BASIC memory each time the ship changes sectors. If you use 32 bytes per ship, starbase, or star, and you limit each sector to 8 objects, you could store the entire game grid in 16K of RAM, or 2 upper memory banks. The simplest way to deal with this is to store your data in fixed-length fields. For different types of objects, you can use object type IDs to separate them. So for example: 0=Ship, 1=Starbase, 2=Star Then your records might look like: Record Type (0=Ship) *1 Ship Name *16 Ship coordinate X,Y *2 Health *1 Energy *1 Torpedoes *1 Cargo *16 Type *1 Qty *1 So how do you get this into and out of upper memory? Let's allow for 48 bytes per object. If we have 8 objects per sector, we would use 384 bytes per sector. That doesn't evenly work out to 8K, so let's make it 16 sectors per 8K bank. With 64 sectors, that would be 4 banks. So to address a sector, we need S (sector), B (bank), P (start position), and N (object Number in sector), and BS (bank size) 5000 REM GET UPPER MEMORY ADDRESS. S=SECTOR 5010 BS=16:OS=48 5020 P=S/BS:B=INT(P) 5030 P=P-B:P=P*BS 5040 B=B+1 5050 P=P*OS+$A000 5060 RETURN if S=0 then P should be 40960. Set S=1 and P should be 41008. Set S=17 and B should be 2, and P should be 41008 First, we get the bank number by dividing by 16. (should be 1) Then we multiply the remainder back out to get the offset within the bank. ( Finally, the first bank is used by the KERNAL, so we need to add 1 to get the next free bank. This assumes your sectors are numbered starting at 0, so: So.... 17 is in in the second bank (B=2) 16 is the first block in bank 2, so 17 is the second. This is 48 bytes in. $A000 + 48 = 41008 At this point, you know the Bank number and Peek/Poke address of each object. So you'd read an object in like this: 2000 S=0:GOSUB 5000 2010 FOR I=0 TO 7 2020 POKE 0,1 2030 ST(I)=PEEK(P):P=P+1 2040 SN$(I)="" 2050 FOR J=1 TO 16 2060 SN$(I)=SN$(I)+CHR$(PEEK(P)) 2070 P=P+1 2080 NEXT 2090 SX(I)=PEEK(P):P=P+1 2100 SY(I)=PEEK(P):P=P+1 2110 SH(I)=PEEK(P):P=P+1 2120 SE(I)=PEEK(P):P=P+1 2130 SM(I)=PEEK(P):P=P+1 2140 FOR J=0 TO 7 2150 SC(I,J)=PEEK(P):P=P+1 2160 SQ(I,J)=PEEK(P):P=P+1 2170 NEXT 2180 NEXT Hopefully, we'll soon get improved BASIC commands to deal with transferring data into and out of banked memory. I created an enhancement request a while back for just this purpose: https://github.com/commanderx16/x16-rom/issues/17 With things like PEEK$, you could simplify the inner loop at 2050-2070 with SN$(I)=PEEK$(P) I've attached a simple BASIC program that simply loads and reads a sector of space. BANK4.PRG
  12. It's not really RAM - it's I/O space. The system is set up so that when addresses within that 32 byte range are selected on the address bus, none of the internal memory chips respond. Instead, an expansion device is expected to set data on the data bus. So if you were going to use DMA to pre-load the system, the CPU would have to set one of those 32 addresses to particular value. The expansion device would be looking for that value at that address, then it would assert the DMA pin, and the CPU would shut down. Then the expansion device owns the bus while it does its thing. That thing can be: populating memory on the Commander, reading from the Commander memory, or even accessing the Commander's I/O devices (including VERA). So, as Bruce suggested, if you had an external processor on that bus, you could even take over the system completely and run it with something like a Z80 or 65816. This is how the CMD super CPU worked, as well as the CP/M cartridge and the 1750 Ram Expansion Unit. However... this requires a "smart" expansion cartridge, which doesn't make as much sense for simply distributing games or software. You'd be adding significantly to the cost to build a CPU onto the cart when all you really need is a PRG file that can be loaded from SD. If I recall, The way Lorin described it was that the startup script would be a bit like a DOS batch file. It would contain a series of BASIC statements that would be executed from a buffer. So a menu program would not actually BE the startup script. It would be called FROM the startup script, which might look something like this: POKE 0,1:LOAD "SERIALDRIVER.PRG",8,1 POKE 2,2 POKE 0,1:SYS $C000 RUN LOAD "MENU.PRG" RUN In this example, you'd be loading a resident routine into bank 1, setting a configuration variable (POKE 2,2) to tell the program which expansion port to use, and then starting the driver (SYS $C000). After that, the startup script would load the menu program into BASIC memory and launch it normally.
  13. First, you don't need to use POKEs to change colors. The Commander has a COLOR command. (You have read the CX16 Programmer's Reference, I hope.) So to change the background to white, you can use COLOR 0,1. However, that only changes the color of newly printed characters - as you have already figured out. The way way to re-color the whole screen at once is to clear it. COLOR 0,1:CLS "But what if I want to change the background without clearing the screen?" You designate one color index for your background, then you edit the palette directly. Here is an example that sets the background to white with red text: 10 P=$FA0C 20 R=15:G=15:B=15 30 COLOR 2,6:CLS 40 VPOKE 1,P,G*16+B : VPOKE 1,P+1,R Line 10 sets the pallete address. $FA00 is the first color index; add 2 for each color after that. The default background is blue, which is 6. So $FA0C would select the "blue" index. Line 20 is our color values. Each color can be 0-15, and you can mix colors. Yellow, for example, is R=15:G=15:B=0 Line 30 sets the foreground color to 2 (the red index) and the background to blue. Line 40 updates the palette entry for blue, changing it to white. If you want to change color 6 back to blue, you can update the value directly: VPOKE 1,$FA0C,$0F:VPOKE 1,$FA0D,0
  14. No, the RAM and ROM cannot be overridden by the expansion slots. The expansion slots get 32 bytes of dedicated address space, so that's not enough for a ROM. Instead, driver software should be loaded from SD in the autorun script. The "cartridge" slot is the SD card slot. User can swap out SD cards and reboot, and an SD card will have some sort of autorun mechanism. The User port is basically 14 GPIO lines, along with some interrupt driven control signals, which can be used for a printer, modem, or which can be arbitrary controlled for other devices.
  15. There's an obvious solution to that. That is exactly what I've started doing. I keep a companion document with variable names and the line numbers of subroutines, so I can refer back to them as needed. While 2-character names still bite, I find that they're a lot easier to deal with when I have a data dictionary right there on the screen. When the eventual BASIC editor for CX16 comes to fruition, I hope it comes with a tool to keep notes in a separate file that we can switch back and forth to at any time...
×
×
  • Create New...

Important Information

Please review our Terms of Use