Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


BruceMcF last won the day on November 10

BruceMcF had the most liked content!


Recent Profile Visitors

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

BruceMcF's Achievements


Proficient (10/14)

Conversation Starter Dedicated First Post Collaborator Rare Posting Machine Rare

Recent Badges




Community Answers

  1. I still wonder whether an I2C DAC and I2C GPIO extender wouldn't work, in which case you can put a pin header on the board and run a small ribbon cable to the I2C pin header, and the slot is just used for the audio lines and power.
  2. If it's all write only, it seems like you can do the bus interface to an MCU with a couple of parallel in, serial out latches and associated glue logic. One latch captures the contents of the data lines, the other the contents of the four lowest address bits. The IO select for the selected slot (which can be jumpered) is connected directly to a GPIO of the MCU set for edge detect which triggers an interrupt to read the contents of the latches, and there is an /ACK flip flop which /IOSelect pulls high, and an /ACK GPIO can be used to pull low when the contents have been read, with the flip flop going out on all data lines when the slot is read from rather than written to. Bus interface lines from the MCU: SCLK (output, preferably hardware universal serial port) SDATA (intput, preferably hardware universal serial port) CLKINHIBIT1 (output, GPIO) CLKINHIBIT2 (output, GPIO) /ACK (output, GPIO) /ALERT (input, preferably rising edge detect interrupt) So it looks something like 6 or so MCU lines dedicated to the bus interface.
  3. If it fits within a 32byte slot in $9Fxx, then there's a /Select line for being within the slot. If you need to halt the CPU while waiting for the bus to be read, a flip flop on the RDY flag, pulled low by the /Select line and reset high by a GPIO from the MCU seems like it would do the trick.
  4. Mastering the bus from the expansion port is not simple, but just having normal memory mapped registers on an expansion card shouldn't be too hard.
  5. Yes, why I said "partially populated" ... You could have connector 1, 2, skip 3 & 4, connector 5, skip 6, 7 & 8, connector 9, skip 10 & 11, connector 12, 3 standard RC2014 connectors, 2 enhanced RC2014 connectors.
  6. If you did that with a partially populated RC2014 backplane, then you could fairly easily transition toan RC2014 card design. A fully populated RC2014 backplane looks like this:
  7. This example is not for sale anymore, but putting a 6502 on a standard RC2014 bus HAS been done.
  8. But if you are loading the game from the SD card, why wouldn't you just save the state of the game in a file?
  9. If you tried to open the same directory twice without closing it, there is no reason to expect it to work on any IEC connected disk drive, so it doesn't seem like it is something the writers of the SD DOS system would try to support either. For that in particular, it's not clear what the point of reading the same directory twice would be. Also, the routine that uses the data in the directory to create the PRG file to load as a directory listing likely does it in a specific location in the relevant HighRAM segment, so it doesn't seem likely that it would be capable of creating two copies of the directory PRG anyway.
  10. I think you can be very confident that monitors with pixel density much finer than most of the input signals they will be showing were designed from the ground up to fill the screen as the default option.
  11. Just speculating, but I wonder whether the repair videos benefit to a greater extent from the flexibility of helping hands placement, in terms of getting the board in a position where the camera can see it, it is well lit, and also it's possible to work on it comfortably.
  12. The directory was originally designed to be used with LOAD in Basic, because the processor in the drive (with its 2KB of RAM in the 1541) is converting the directory into the format of a Basic listing, so directory display can just re-used the existing LIST keyword. I presume that the reason to OPEN it is that you are emulating a LOAD but you are putting the data somewhere else (eg, HighRAM). I do not know whether any file you open in LOAD mode will be corrupted or just the Directory, but it makes sense that the Directory would be.
  13. If the updated I/O section of the PRG is correct, bit banging burst mode is supported via the CB1 line connected to SRQ, but the fastest burst mode is not supported. @Kevin Williams evidently does not have the CB2 line connected to IECDATA. In regular mode it would be set to input (so that it floats), in burstloader mode it would be set to input for input mode, in output mode the regular DATA is set to input (so IT floats) and the serial shift register is output in burst mode.
  14. Look in the X16 programmers reference guide Kernel section.
  15. Like they thought, "hey, this is a noticeable speed up with only a need to change the code in two very low lying KERNAL routines, and then we can fit other things into the KERNAL ROM." Tramgineering. But the X16 has the MACPTR to justify implementing the bulk burst mode transfer, and then that transfer can be used by LOAD if the device supports burst mode.
  • Create New...

Important Information

Please review our Terms of Use