Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


TomXP411 last won the day on June 27

TomXP411 had the most liked content!

Community Reputation

38 Excellent

Recent Profile Visitors

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

  1. I'm pretty sure we'll get at least two DIY options... I'd be really surprised if there's not an option to buy a naked board, and there has also been talk about a kit version that you can assemble yourself. While I have zero interest in soldering everything in myself, I might buy a second, bare motherboard, so I can do something like put it in a project box with a 7" LCD on the front.
  2. You can have all metal cases cut, bent, and painted for maybe $100 per unit, and industrial monitors should go for a similar number. It's not especially cheap, but not crazy expensive, either. I'd definitely pay the extra $150-200 for something with a 7-10" monitor in a Kaypro II / SX64 form factor. These guys will do custom enclosures, for example: https://www.protocase.com/price/instant-output.php Now those are simple, metal boxes.... but it's one way to get a simple, portable enclosure. I've been thinking of building a NuPro (KayPro clone) using one of these enclosures, but a one-off is $300. If I do 10, the price comes down to around $200 each. If we could get 100 or 1000, the per-unit price would drop. Maybe that's something to prototype and investigate for the third, FPGA design, since we (interested customers - I don't speak for the CX16 team) could build it in a smaller case - something closer to an oscilloscope, rather than a suitcase sized PC.
  3. Now the big question.... why not just put VERA directly on a Z80 board? A VERA daughterboard for RC2014 should be simple to build, and then we could have a stand-alone "Commander ZX80", which could run at 20Mhz and not need any fancy interface logic to work with the CX16.
  4. Yeah, I kind of took it for granted that something an Apple Z80 card wouldn't work, because we've only really got 40K or so of RAM available without additional help. So to get a 60+K environment, you'd need to either add RAM on the Z80 board or play tricks with the banked memory on the Commander. However, if you have to add 32K of RAM to the Z80 board, it makes more sense just to go with the full 64K and not even try to use the Commander's RAM for the Z80. That thought evolved into the thing I proposed. @BruceMcF have you done anything with CPLDs? Maybe the solution to both our issues is to implement something like 4 16550 UARTs, running two of them to a Z80 board, one to a rear panel DB25, and one to an ESP32. Then we could work out the design to an all-in-one board that acts as a CP/M computer, a WiFi adapter, and a serial interface.
  5. I'm already planning a serial terminal for the CX16. I'm just waiting to see how the hardware situation shakes out. Since we now know that the on-board serial port will be software serial, I'm less enthusiastic - but I'll probably still build something that uses the KERNAL for serial I/O. A CP/M cartridge will be slower than the Commander - by about 2.4x, unless you put RAM on the card and just pass video data out to VERA - but it's certainly possible to do. I suggested an RC2014/CX16 bridge on the last FB thread where someone talked about a Z80 card. Here's what I'd probably do if I was going to build a CP/M card: rather than just have the Z80 CPU freeze the 6502 and take over as bus master. I'd build a bridge that uses a chunk of the 32 bytes set aside for the expansion slot I/O and basically emulate a terminal, disk drive, and memory access: So it might work like this.... 0: CPU control: bit 1 Stop, 2 Reset 1: Terminal status register. Bit 0: byte waiting to be read by Z80. 1: byte waiting to be read by 6502 2: transmit byte (Z80 writes) 3: receive byte (6502 writes) 4-5: set memory address - this is the 16-bit address used to read or write in the Z80 RAM. 6: step value - how many bytes to increment when memory is read or written (use the same values as VERA) 7: write to set memory in Z80 RAM. read to read from Z80 RAM. Doing so will stop the Z80 for the duration of the read or write operation 8: disk command, written by Z80 (ie: seek to track, seek to sector, sector read, sector write, open file, close file, file read, file write, file seek, etc....) 9: transmit parameter/data (Z80 writes) 10: Response status (6502 writes) 11: receive parameter/data (6502 writes) 12-13: CPU address bus 14: CPU data bus 15: Application Status Register (ASR). This is a shared value that can be set by the Z80 and 6502 and read by both. 16-31: 16 bytes of buffer space. This could be used by disk command parameters or for application data exchange. Disk I/O would basically need to be written from scratch, since you really want file-level access, and CP/M is a block oriented system by nature. The terminal I/O could be designed to work just like the 88-SIO, so CP/M for the Altair 8800 could be used as a starting point. This design would also allow the Z80 to be used as a fully independent co-processor. You could stop the CPU, load up some data in RAM, and reset the CPU. It would then run the program. Once the program is done, the Z80 could set a value in offset 15, and the 6502 could go in and read the results. The Z80 should also be able to trigger the IRQ line to get the 6502's attention.
  6. 2MHz should be reliable enough. C128s were sold with both models of SID chip, and those were definitely used at 2MHz. It sounds to me like a first task for third party developers would be to build an 8:1 clock divider, along with some sort of buffer to read from the CPU bus and stretch that cycle on the expansion card side. If we're only talking about writing data (to a SID or VIC), then that should actually work fairly well. I'm just not sure what kind of hardware that would require - I expect a CLPD would be the device of choice, with address and data latches. I think I even have a process to make it happen, but I know nothing about programming CLPDs.
  7. Can that hardware address devices in the expansion slots, or just the YM and SAA chips?
  8. My 2 cents worth... do NOT load assembly code directly to $801, unless you have a SYS statement built in to the program. Instead, either start your program with a SYS statement, or load to a higher address (such as $2000) like you're already doing. Ideally, you should change the top of BASIC pointers to protect some memory for your program, but I'm not going to get into that here. I use 64TASS for 6502 and 65816 assembly. I'ts simple to use,doesn't require any complicated setup, and the whole program is 1 file. Just drop the EXE in the same directory as your assembly files and either assemble from the command line or create batch files for each project. Actually, there's a simple trick you can use, as long as you don't modify any BASIC lines once you've loaded your program. Start your program like this: * = $801 ; 10 SYS $810 DB $0D, $08, $0A, $00, $9E, $20, $24, $30, $38, $31, $30, $00, $00, $00, $00 ... your code goes here If you look at the anatomy of a BASIC program, it looks like this: 2 bytes: the start address of the next line of code. 2 bytes: the line number (in 16 bit binary format) n bytes: BASIC tokens (any value >= 128) or ASCII characters (values < 128) 00 end of line ... repeat for each line 00 end of program Here's what it looks like in memory: So the DB line is actually: 0C 08 - the next line of code starts at $80C. Since this is the last line, $80C is just zeros. 0A 00 - This line number is 10. (You could make this anything you wanted, as long as it's a 16-bit integer.) 9E - SYS statement 20 - space 24 - ASCII $ 38 31 30 - ASCII "810" 00 - end of line 00 00 - if you count the bytes, this should be location $80D. The 00 00 means "this is the end of the program." If always start stand-alone ML programs with that sequence, you can then always start your programs with a simple RUN statement. Keeps things nice and simple.
  9. People bring up the 6551 because this is the chip used by the Swiftlink and compatible serial cartridges for the Commodore 64. This design is simple, only needs a few components, and the code is already out there to support this chip. Someone could port a terminal program from the C64 to the Commander very quickly by just modifying the screen output code and the I/O address for the serial port. At first, I was against using the WDC 6551, due to the register bug, but as long as is this is only on the transmit register, it's not actually a problem: programs just need to wait for 10 baud units of time before writing another byte to the data register. There are several ways this can be done, including using a programmable timer on one of the VIA chips. I have written code for the 16550 UART as well, although it's been 20+ years. However, there aren't any public, baseline designs we can draw from when building interface cards, like there are with the 16550. The 16550 is not designed for the 6502 bus, and so it will require additional hardware to couple to this CPU.
  10. TomXP411

    ISA support

    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.
  11. @Kevin Williams This looks great! I feel like it's 1985 again, and I'm trying to figure out whether to buy the disk drive or the 9" black and white TV....
  12. No, ISA doesn't really make any sense, since the 8088 architecture is too different. Making this ISA compatible would require and extra 4 bits of address space, and a way to generate the IOW and IOR signals. The 6502 also reads and writes in a single, two-phase clock cycle, while the 8088 has a total of four clock cycles per bus cycle. You could interface with an ISA bus through some sort of intermediary, such as a VIA or CLPD, but that's going to require extra hardware and doesn't really give any tangible benefits except partial compatibility with devices designed for PC (and which often use device drivers that take up more memory than the whole of the non-banked RAM on the Commander.) There are common bus standards that would work, including the RC2014, but even that would have required an intentional design choice from the beginning.
  13. While that would be cool, I think it's not likely at this point. The team IS building a ROM based assembler IDE, which will be much more powerful than BBC BASIC's assembly. You should be able to drop in and out of the assembly editor at any time, so you would just need to use SYS statements to run assembly subroutines from BASIC. With the planned BASIC editor, which will not require line numbers, the CX16's code editing will be more advanced than any 80s micro.
  14. We've had that conversation, too: the send data status register bit is defective on WDC units, and that is not a problem with other manufacturers' units. Just buy a different brand, and it's all good. Since this is the chip used in the Swiftlink cartridge and the clones, it's the easiest one to adapt for the CX16 - there's already tons of software out there that uses it, and we wouldn't need to re-write the serial I/O routines. We can just adapt an existing circuit and existing code to make it work. Here's an example of a Swiftlink clone with an ESP32 to show what I mean... it's a super simple board: https://www.lemon64.com/forum/viewtopic.php?t=75130
  • Create New...

Important Information

Please review our Terms of Use