Jump to content


Super Administrators
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by TomXP411

  1. Hello, everyone. I have a bit of sad news to relay. https://www.mcdougalfuneralhomes.com/obituaries/scott-robison Scott Robison passed away suddenly last month, on August 16. (We just found out tonight - apparently, Scott's wife didn't have the passcode to his phone.) Scott was an invaluable contributor to the Retro community. He made some major contributions to Attack Of The PETSCII robots, was a frequent poster on the forum, and was a fun guy to talk to. We are all going to miss him.
  2. We don't actually know, yet. The assumption at the time was that he's going to launch some sort of crowdfunding campaign, but he could choose to just open up orders on his web site, https://www.the8bitguy.com/ I'm also sure that you'll get plenty notice when the time comes. There will be an announcement on his YouTube channel, his Facebook presence, and here (of course.)
  3. To be clear: we are holding the site in trust for 8-Bit Productions. We're happy to hand the domain and management over to David, should he ask for it. However, my understanding is that he's not interested in managing a forum - which is why a few of us decided to step in and take up the responsibility for the site in the first place. Otherwise, it would have been closed, and the information and software we'd already collected would have been lost. So I can't say what's actually going to happen when the computer launches. If I had to give it my best guess, David will likely sell the computer on his web site, and we'll continue to maintain this as a place for users to connect and learn.
  4. Don't get me started on how much I hate intros and cracktros. What's worse is the new trend of "cracking" and adding intros to free and unprotected games. What's the point of that?
  5. There is no configuration GUI for the emulator, that is correct. And there are really only a couple of command line options. The one you need, in this instance, is the -sdcard option. You need to load your files into a disk image and use the -sdcard option to specify the image you're loading, like this: x16emu.exe -scale 2 -echo -sdcard image_file_path The file types you can use are IMG or VHD. If your files are not in an image file, you can create one using the instructions here:
  6. Wow. This is off topic... but the whole "send a check or money order"... you'd have no idea if a company is still in business, or how long it would take to get stuff. I remember that as a kid, I had some older comic books, and one time I decided I wanted to order "100 army men". So I got $2 from my piggy bank (it was actually a little safe with a combination lock) and sent it off. I never got my army men or my money back.
  7. If you mean 640 rows - then no. The video chip generates an 800x600 image cropped to 640x480. That's actually the only physical screen resolution. All of the lower resolution modes are actually scaled up to fit the 640x480 viewport, so if you want to display a 40x30 text screen, for example, VERA actually scales the pixels 2x horizontally and vertically. As a result, It's actually possible to emulate text modes from lots of different vintage computers, which is great for porting software from machines like the VIC-20 or ZX Spectrum.
  8. There's certainly no harm in doing both. Have the default directory in the directory header, along with a separate "get directory" command. I'm sure that there is a way to read the current directly directly from RAM; I just haven't bothered to look through the code to figure out where that is stored. If you know where the variable is, then it's just a matter of reading it, rather than using a DOS command. FYI, looking at the SD2IEC documentation, there is now PWD equivalent, as far as I can tell. Since SD2IEC's commands are based on the CMD hard drive, I'm assuming this isn't in the CMD command set, either.
  9. Honestly, I'd rather see a PWD command, or see CD return the current directory. I don't want to have to load the whole directory, just to see what the current directory is. So CD by itself would return the current directory, like this: 10 OPEN 15,8,15,"CD" 20 INPUT#15,D$ This would imply that CD with an argument returns the newly selected directory, which I'm fine with.
  10. Why would you not want to use the existing declarations? If you did want to write your own KERNAL wrappers, you'll want to use inline assembly, since most KERNAL functions take their parameters on the Accumulator, X or Y registers, or various flags. You need assembly to manipulate those values directly. I'd suggest looking at how other library functions do it to get how to interface C code and assembly code.
  11. IMO, all other things being equal, simpler is better. And this won't even be equal, since there are performance and efficiency benefits. Integrating directly onto the system bus means fewer parts, less code, and I'm betting the data packets can be read in far fewer steps. So given the choice, I'd definitely choose the larger micro controller attached directly to the main bus.
  12. Actually, I think it's being done the best way possible: anyone can download the libraries and compile their own, fixing the issues that spring up from version to version. The emulator includes symbol tables that list all the labels used by the operating system. If an entry point gets moved, you can look it up in the symbol table and fix the library. Or you can even re-write routines to use the fixed, public APIs where needed. That stuff is usually fairly simple to do. I have written a few system access functions for both cc65 and Kick C myself. They are actually all very simple, and usually just a wrapper for the KERNAL functions. Here's the source for cc65: https://github.com/cc65/cc65
  13. 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.
  14. The obvious problem is that different people will want to store their utilities in different places. The solution is probably to store the path in memory, either using a configuration file, or take the CP/M approach and patch the executable with the desired path. (That would be faster, although it would require a separate "patch" program that knows the address of each of the pre-configured filenames.)
  15. In theory, but it would require changes to the expansion slots, and it would make the extra RAM more expensive, rather than less. At this point, if they want people to actually be able to use 2MB of RAM, the cheapest alternative is to leave the sockets in place on the board, but not populate them.
  16. Greetings and welcome. The computer will not have a built-in MIDI port, but there are plans to build add-on cards. Among other things, there will be a breadboard card, which someone could use to build a MIDI interface using a 6850 ACIA. As that's the chip used in most Commodore MIDI interfaces, it should be pretty straightforward to translate that to the Commander.
  17. Yes. It can be any byte value. I don't remember if zero was valid, but definitely 1-255 are. I actually ran my test program with 1-255 for all valid secondary addresses, and it worked.
  18. I'm also a little surprised, looking at this. It turns out that Position uses the Secondary Address, not the file number. So this should work: OPEN 1,8,2,"TEST FILE,S,R" OPEN 15,8,15,"P"+CHR$(2)+CHR$(64)+CHR$(0)+CHR$(0)+CHR$(0) This will not work (using file number in the P command): OPEN 1,8,2,"TEST FILE,S,R" OPEN 15,8,15,"P"+CHR$(1)+CHR$(64)+CHR$(0)+CHR$(0)+CHR$(0) and this will not work (using device number in P command): OPEN 1,8,2,"TEST FILE,S,R" OPEN 15,8,15,"P"+CHR$(8)+CHR$(64)+CHR$(0)+CHR$(0)+CHR$(0) So where we all got it wrong was assuming "channel" meant the LFN, or Logical FIle Number, aka the lfn in OPEN lfn, device, sa That is why you thought that the LFN and the SA needed to match: they did not need to match, but if you were using the LFN with the Position command, it would obviously not work. Here is the test program I used to figure this out. It tests all permutations of LFN (up to 15) and SA. You can change the FOR loops to test other values and change the SA in 170 to LFN to see what happens when you try to use LFN in the P command. 10 OPEN 8,8,8,"TEST DATA,S,W" 20 FOR I=1 TO 255 30 PRINT#8,CHR$(I); 40 NEXT 50 CLOSE 8 100 PRINT "LFN","SA","TEST","GOT" 110 FOR SA = 2 TO 14 120 FOR LN = 1 TO 15 : REM CAN BE 1 TO 255, CAPPING AT 15 FOR BREVITY 140 PRINT " "," \X91" 150 PRINT LN,SA, 160 OPEN LN,8,SA,"TEST DATA,S,R" 170 OPEN LN+1,8,15,"P"+CHR$(SA)+CHR$(64)+CHR$(0)+CHR$(0)+CHR$(0) 180 GET#LN,A$ 190 IF A$=CHR$(65) THEN PRINT "PASS\X91" : GOTO 210 200 PRINT "FAIL ", ASC(A$), : DOS 210 CLOSE LN 220 CLOSE LN+1 230 NEXT 240 NEXT
  19. It's entirely implementation dependent: it will be different for a disk drive, a printer, the serial port, and whatever other devices you can imagine. Specifically, with the disk drive, there are 3 reserved values. 15 is the command channel. Sending data to this channel issues DOS commands, rather than writing to disk. 0 is used for LOAD 1 is used for SAVE I'm going to circle back around to my earlier statement, I think either your code or the C library you're using is either mixing up or swapping the channel number and secondary address. You should probably audit the code and confirm the correct usage of the carry flag, and the correct values in .A, .X, and .Y in all of the KERNAL calls. I don't see any of the problems you're describing when using BASIC, so your confusion is likely due to bad code, not the KERNAL API.
  20. Simplicity. Building a backplane design requires more parts and more complexity. It also means you need to deal with a lot of problems that don't happen on an SBC. Among other things, a single-board computer is more structurally sound. Since most people will probably never slot a card in their CX16, there's no reason to make the system more complicated by requiring the use of cards when most people won't use them.
  21. Let's be clear. In CMDR-DOS, the P file only works on Sequential files, because the system does not support REL files. In CBM-DOS, the P command only works in REL files, because that's what REL files are for. The LFN and SA don't need to match. I tested this while helping ZeroByte troubleshoot his C code. Whatever's going on there is a bug in the C runtime, not CMDR-DOS. I actually tested explicitly using different Logical File Number and Secondary Address, and P works just fine. (ie: OPEN 3,8,5).
  22. There's a difference between issuing the U1 command, which takes care of the hardware access, and having to manipulate the SD card using raw SPI commands. Using the SPI port is akin to having to directly operate the stepper motor and read the raw GCR data on the floppy diskette... there's a whole layer of APIs in between that and Read Sector. That's actually implemented in CMDR-DOS (it has to be) but there are no public APIs for it, yet.
  23. That's a little too raw... ideally, the CBM-DOS U1 and U2 commands should be implemented, as is demonstrated here: https://wpguru.co.uk/2016/01/how-to-use-direct-block-access-commands-in-commodore-dos/ The available commands are listed in the DOS manual, which is not part of the emulator release. You need to dig it out of the README for the ROMs, here: https://github.com/commanderx16/x16-rom/tree/master/dos According to the manual, the answer is "Not Yet".
  24. No. The screen address is hardcoded to $1b000 in io.inc, and the screen_set_char and screen_get_char routines set the address using this hardcoded value. Also, there is no published method in the Programmer's Reference, which means that even if there is a routine that simply returns the screen_addr constant, it's not in a fixed location that will remain static from one KERNAL revision to the next. What would you expect a routine like this to do? Would it just decode the address by shifting it left 9 bits, then return that as a 3 byte address? Maybe it could write the address to a pointer specified by .Y and .X...
  25. The only thing I'd caution you on is that the x86 and AMD64 instruction sets have long passed the complexity level where hand coding is simple. With thousands of instructions, you may find yourself writing a complex operation using several opcodes, not knowing that buried in the thousands of opcodes in the system, there may be a single opcode that actually does the same thing, much more quickly. Modern chips are actually optimized for compilers now, rather than hand-coded assembly. You may also find out that the majority of the system's time isn't tied up in the emulator itself, but in the libraries. SDL is not a perfect rendering engine: It's a cross-platform wrapper for system libraries, and it's not really meant for the kind of use it's being put to here. Emulating VERA at the pixel level means updating the screen at least 12 million times a second. One approach may be to change the display engine, targeting a different library that is more efficient - or at least uses fewer layers to get to the screen. Perhaps bypassing SDL and doing something with Direct 3D and shaders is the answer...
  • Create New...

Important Information

Please review our Terms of Use