Jump to content

BruceMcF

Members
  • Posts

    1328
  • Joined

  • Last visited

  • Days Won

    48

Everything posted by BruceMcF

  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.
  16. The VIC-20 / C64 / C128 KERNAL operations are done a byte at a time. Both fast mode and burst mode have to first get the other side into burst mode, but fast mode does it for every byte, while burst mode does it once for a series of bytes. LOAD could be rewritten to use burst mode instead of fast mode, but in the C128 KERNAL it is not.
  17. Warp speed was the one I had in grad school in the early 1980s. I originally got it as Warp Speed 128 for the C128D that I fried by plugging in a power tap to the cassette port upside down, but it had a switch between C128 and C64 mode, for when the C128 was in C64 mode, so I switched it to C64 mode and used it with my C64. Reiterating previous discussions on this topic: C128 Fast Mode on the 1571 is around 1600byte/s and burst mode on the order of 4000bytes/s. Since it is an asynchronous protocol that acknowledges each bit received, it runs as fast as the slower of the two sides of the transfer supports, so an X16 burst mode with a SD2IEC modified to support burst mode should be able to beat the SD2IEC w/fastloader numbers above.
  18. I was happy to see that the VIA#2 appears to be an empty socket on the board rather than left using up an expansion slot. I would of course be interested if @Kevin Williams has any spare time to say what pins are where on what appears to be the associated pin header.
  19. Since there is an 8bit latch holding the ROM bank specification, and the picture says ROMB0 - ROMB7, there is your answer right there: they are bringing out all of the ROM bank latch.
  20. Look at the picture. It is a ROM address, not a fully decoded output. RTFM, it is analog video outputs from Vera.
  21. It would allow a bus mastering card to use the capabilities of the Vera. But the Vera does what it does. The wiring of the Vera logic resources is not going to be modified by anything plugged into the expansion port, any more than anything plugged into a C64 cartridge port would modify the operation of the VIC-II video chip. The expansion board card does show it still has Audio_Right and Audio_Left, so mixing what is done by the built in X16 audio source (FM chip, PSD & PCM) with additional resources on an expansion card (SID, MIDI Wavetable, etc.) seems like it would be definitely do-able.
  22. Note no motherboard User Port, which had been raised by Kevin on Facebook as a possibility ... the I2C pin header is one pin short of being able to bring out PB0-2, CA1/2 & CB1/2, and since he mentions the routing being tight, the routing might not work anyway. Since the serial shift register is needed for IEC burst mode, bringing out PB0-2 & CA1/2 on the I2C pin header NCs and redundant GNDs and wiring CB1/2 to support burst mode on the IEC port bears mentioning.
  23. That is only one year after the "1977 trinity" of PET-2001, Apple II and TRS-80.
  24. The burst mode is covered Pasi Ojala in presenting his burst fastloader for the C64 (with User Port support). Note that the same modification wouldn't be able to be done for the stock X16, since the C64 has a CIA, so there is no CNT pin in VIA#1. But the equivalent can be done with CB1 and CB2, with CB1 taking the role of CNT and CB2 taking the role of SP. So the routine would have to be modified for the VIA hardware registers as opposed to the CIA registers, but the same basic approach can be followed, if CB1 and CB2 are available from a X16 motherboard User Port pin header.
  25. The burst loader protocol is faster, since it is a protocol where recipient acknowledges receipt and then the sender can send another bit, rather than running at a clock rate set to accommodate the slowest device that may be on the serial link. So if you have an SD2IEC type device built on an ATTiny with a 12MHz clock and replace it with one with a 20MHz clock, the top speed of that device in burst mode goes up. If you have a bit banged IEC run by a 65C02 running at 8MHz and upgrade to a VIA#1 hardware-assisted big banged IEC, the top speed of the X16 side of the burst mode goes up. Also, since it's an already standard protocol, burst mode would have a larger ecosystem. A burst mode SD2IEC kind of device also works on a C128, or on a C64 with the User Port supported burst mode, and an X16 with burst mode also allows a real 1571 to be accessed faster than a 1541. It makes a 1581-clone a combined device for both retro C128 and X16 owners, and pooling multiple niches together might be what gets it over the economies of scale hurdle.
×
×
  • Create New...

Important Information

Please review our Terms of Use