Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by BruceMcF

  1. As a long time Galaxian fan, I'm really interested in a game with a shot quota, but "bigger than one". One alternative to a delay on the follow up shot is to allow the follow up shot when the current shot explodes OR passes a certain part of the screen. So, say, in level 1, if the first shot is 40% from the top or higher ... OR exploded ... its follow-up is available. The in level 2, it's 60% from the top, or higher ("congratulations, your fire control has been upgraded!"). Then in level 3, it's back to level 1 but there are two independent "tracks" ("you can been upgraded to two torpedo tubes!"). Then in level 4, same as level two but two independent track.
  2. And for people used to NMOS 6502 coding, you don't have to allocate a memory location for the bit ... on the 65C02, BIT #1 works.
  3. PS2 would require more pins and have a bigger Kernel footprint. NES/SNES is Select, MISO, SCLK, while PS2 is Attention, Acknowledge, MISO, MISO, SCLK. You can do two SNES with four pins, while two PS2 requires a minimum of seven (since MISO, MISO, and SCLK can all be bussed). "More buttons" tilts to SNES in part because they have identical interfaces from the system side, you just read 8 bits from an NES and 16 from an SNES. So you get more buttons WITHOUT using taking any GPIO away from the User Port.
  4. If you group the star charts in 4x4 groups, that's 125 files for 2000 star systems, and each file is 128K, occupying 16 segments. You could have a rectangular master map and compute which cluster you need when leaving a system that is on the edge of a cluster. And with only 125 files, each "cluster" map can be indexed with a single byte, so you can have a linked master map and aren't limited to a rectangular master map if you don't want to be.
  5. It's a little confusing because the pinout is given from board side rather than connector side, and the block header is not numbered in the same way as the DB-25. CA1 is on DB-25 pin 10, which is an input pin, ACK in the Centronics parallel port, Interrupt in the enhanced parallel port (rising edge). CA2 is on DB-23 pin 11, which is an input pin, BUSY on the Centronics parallel port, WAIT/READY on the enhanded parallel port. I don't know if ACK is an edge or a level, but in any event since it is a response to the data being written, you can be sure that you are ready for it if you need to set up CA1 to detect it. CA2 on BUSY is a mistake for the Centronics parallel port, because BUSY is not an event, it is a state, so it should be connected to GPIO. It makes more sense to put CA2 on paper-out. Then even if you miss the edge, the BUSY will be high and the printer itself should also be indicating paper-out when we look to see why it isn't printing. PB4 is on DB-25 pin 15, an input pin, which is Error|Fault for Centronics (not used in EPP). If it is low, it means no error. If BUSY is high, you check whether Error is also high to determine whether it makes sense to wait for the printer to stop being busy, or whether to tell the user that there is a problem with the printer.
  6. To clarify this, according to the block header pin numbering above (the standard documents use the DB-25 pin numbering), for the standard EPP port used by a variety of "parallel port" devices in the 90s: "Odd" side of block pin header: 1 = Write (PB0) 3-17 (odd) = D0-D7 (PA0-PA7) 19 = Interrupt (from device) on rising edge (CA1) 21 = Wait (handshake from device, cycle starts when Wait=0, is finished when Wait=1), (CA2) 23 = Spare (PB1) 25 = Spare (PB2) "Even" side of block pin header: 2 = /Data Strobe (value read/write at current port address if /Data=0) (PB3) 4 = Spare (PB4) 6 = /Reset (device reset when low) 8 = /Address Strobe (port address read/write if /Address=0) (PB5) 10-24 = GND The two issues are: (1) using the CA2 for the Wait handshake is awkward, because the mode of CA2 has to be changed twice a cycle and if the change is too slow, it will miss the edge transition. Meanwhile using a GPIO makes it simple, set it as an input and AND a mask to read whether it is 0 or 1. There is a similar issue using it as a "BUSY" line in a Centronic Paralllel printer interface. The idea appears to be to be that you can drive an interrupt on BUSY, but the BUSY state can easily pass before the interrupt is served and the mode of CA2 is switched from falling edge to rising edge detect, missing the end of the BUSY state. Also, you don't really need to be interrupted to learn about the BUSY state ... a Busy state only matters when trying to output, and in that situation a regular check on a timer interrupt would often make more sense than setting up an IRQ interrupt on BUSY going low. For checking on a regular timer interrupt, it is more convenient if BUSY is on a GPIO. For the Centronics parallel port interface, it makes more sense to connect pin 23, Paper Out / End to CA2, since that is a state where you are more likely to want to interrupt the regular output process, and to connect pin 21, Busy, to PB1. This fixes the EPP issue at the same time. (2) Being unable to generate a device /Reset without resetting the CX16 system. One solution is a jumper between the line resetting the VIA and PB4, which would mirror PB4 on pins 4 and 6. You wouldn't want to do that in Centronics output mode (this would bridge the Fault input and the Initialize output) ... so that would be a jumper to choose between Centronics and EPP mode. A second solution is a jumper between the line resetting the VIA and CB2, as CB2 can easily be to output either a high or a low. If Power is put on a different line (or pin 26, which is not connected for a normal DB25 cable), then a second block jumper between CB1 and pin 10 would make it possible to put all available resources onto a DB-25 for any CX16 specific interface.
  7. If they were the distributor, they would obviously be much less hesitant.
  8. The physical format is stated, it's the same as the Apple2 backplane connector. That is still in production -- even if it is more for the industrial market which also uses them than the Apple II market
  9. We do know that if it's coming from the built in SD card port, Vera is reading the data in from the SD card, which is an SPI interface with a 12.5MHz serial clock, so in the middle of a block read, the process of writing the output byte to $9F3E, reading $9F3F until bit7 is clear, then reading the input put from $9F3E is going to be about half the speed of a memory to memory copy, if it is properly interleaved. Add the file system overhead to set up which block is being read, perhaps a third of the speed of a memory to memory copy. That seems likely to be part of why Vera was redesigned to bring out the registers which were previously accessed through the data ports ... direct copy from the SD drive to the VRAM works much faster if the SPI port can be accessed directly and then written to the data port where the auto-increment writes it to the correct location. ; Block read ready, VRAM port A destination & increment already set up ; Y is the byte countdown, X holds the dummy value to write to trigger the SPI transfer LDX #0 TXY STX SPI_DATA - LDA SPI_CTRL BMI - LDA SPI_DATA STX SPI_DATA STA DATA0 DEY BNE - ; (Next I assumed a 'DEC N' on a memory register is going to test whether more pages need transferring) ... note that would certainly busy wait in the first byte, because a maximum byte transfer frequency of 1.5625MHz can't keep up with a 4-clock instruction which has an effective instruction frequency of 2MHz plus, but storing the dummy to start the next SPI cycle immediately after reading the previous SPI data received means that normally the busy will be cleared by the time the loop restarts at SPI_CTRL ... a 13 clock 65C02 sequence has an effective frequency of 615kHz, so the SPI port is plenty fast to keep up with that. But this is a block transfer that has already been set up. One choice that is likely going to be needed in a number of games is whether to load video assets straight into VRAM from SD card in a double buffered arrangement and feed audio from assets stored in High RAM, or to load, in particular, PCM assets straight into Vera's PCM ports, and load video assets stored in High RAM.
  10. Since the MiSTer system is the kind of thing where many of its users will be heavy users of bootleg ROMs, it would not be surprising if Cloanta was hesitant to see the CX16 on MiSTer.
  11. Note that this is all CX16p ... the memory situation for CX16c and CX16e is unknown. For instance, it might be cheaper to have one surface mount 1MB RAM in the CX16c and skip the RAM sockets, and the RAM in the CX16e might be internal to the FPGA and dependent on the specific FPGA used.
  12. There you go. I use acme and Notepad++, and since I am normally grinding through on the same project day after day, batch files <mainfilename>_make.bat and <mainfilename>_run.bat.
  13. A development environment that calls the assembler of preference would be fine, but what would be lovely is a cross platform assembler development environment which has a common user interface with a hosted assembler development environment. And that should have a common user interface to the "Super-Monitor" in ROM.
  14. SEQ and DAT especially for sequentially read/written text and binary data respectively. REL was more for relative files, which I used quite extensively back in the day, since the C64 version of fig-Forth I used in the 80s used relative files for block files.
  15. Go for it. My physical test units are whichever of my C64's still work, if either of them do, and they are on the wrong continent for me to access, so I am focusing on bringing up my port of eForth.
  16. Certainly not if they can help it ... one of the design goals is a stable target for programming. A blizzard of individual FPGA hacks and tricks would run directly counter to that design goal. The aim is to make the Vera as much as possible like the custom ASIC video chips of the 8bit machines, and see what people can do within the constraints of the platform. There already are chameleon systems out there, it would be pretty redundant to be working on making another one.
  17. Quite. While "PAL" stands for "Pretty, but Annoying Lag", NTSC stands for "Never The Same Color".
  18. If using CA2 pulse as SCLK (which works), that is: PA0-3 MOSI PA4-7 SS (4 devices) PB0-3 MISO ... because if you put MOSI and MISO on Part A, CA2 pulses for every write AND for every read, so bidirectional read/write (as when status of the write is returned on MISO) becomes impossible. Having a SS mask somewhere, you can have the four bits out in A, "AND SS_setting : STA VIAxPortA " and the pulse is triggered, so you can read PortB for the input. With one line, you only need one bit of Port A, since CA2 can work as the SCLK and the serial shift register can be the input by tying CA2 to CB1. Since SPI shifts low bits first and the 6522 VIA enters input at bit0 and shifts it up toward bit7, it's most convenient to have PA0 be MOSI ... you also would want a page that has the reversed bits at each page address ... eg, address Page+%00110101 contains %10101100. LDX #7 STA PortA - LSR STA PortA DEX BNE - LDX SREG LDA BItFlip,X RTS ... which at 110clocks is appreciably faster than bit banging the SCLK but a hardware PHI2/2 SCLK SPI s 11 clocks JSR/RTS, 8 clocks write output byte, read input byte and 16 clocks to transfer, or about 35 clocks. So throughput is about three times faster with full hardware SPI than with CA2 output pulse SPI. A 6522 SPI is natively Mode3 ... a downward pulse for a clock and latching the outputs/inputs at the trailing edge of the clock. Mode0, with an upward pulse for a clock and latching outputs/inputs on the leading edge, requires an AND gate and a control bit, to hold the clock low and manually release it so the leading edge of the CA2 pulse is treated as the trailing edge of a "long" first clock and the trailing edge is the leading edge of the next "long" clock. LDX #7 LDY 1stState STY PortB STA PortA LDY FollowState STY PortB - LSR STA PortA DEX BNE - LDX SREG LDA BItFlip,X RTS ... which adds another 16 clocks to the overhead for routine. Then a second control bit which inverts SCLK when set (through an XOR) would give all four modes. In both of those circuits, it is the unmodified CA2 which is connected through to the CB1. Two PortB outputs for mode control and four for DeviceSelect exactly fits the six available. If PB0-3 are the Device Select, PB4 the CA2 Through/Filter, and PB5 the clock invert, the Setup is A=Mode#, Y=Device# SETUP_SPI: AND #3 TAX LDA SPIMODE0,X ORA SPIDEVICE,Y STA 1stState ORA #$10 STA FollowState RTS SPIMODE: !byte $00,$30,$20,$10 SPIDEVICE: !byte $01,$03,$07,$0F
  19. On addressing, remember that the state of all PortB output lines can be set in parallel. Also, it isn't necessary at the outset to allocate things to the Centronics output-only parallel printer port pint allocations when the User Port is not ACTUALLY a Centronics parallel port, but rather a set of VIA pin allocations that can emulate a Centronics parallel port. That suggests to me a dedicated "reset register to 0" line. The CA1/CA2 handshake is dedicated to the "/Port0" operations. So, to read from a "high" register, A=x, Y=register address. Note, "Wait/Ready" is GPIO input, not CA2. (1) R/W=0, /Address=0, /Data=1, /Port0=1 (2) Wait/Ready=0? (3) Write Register address (4) Wait/Ready=1? (5) R/W=1, /Address=1, /Data=0, /Port0=1 (6) Wait/Ready=0? (7) Read register contents (8) Wait/Ready=1? (9) Return, A=contents, Y=register address So, to write from a "high" register, A=contents, Y=register address: (1) R/W=0, /Address=0, /Data=1, /Port0=1 (2) Wait/Ready=0? (3) Write Register address (4) Wait/Ready=1? (5) R/W=0, /Address=1, /Data=0, /Port0=1 (6) Wait/Ready=0? (7) Write register contents (8) Wait/Ready=1? (9) Return, A=contents, Y=register address To write a packet: (1) R/W=1, /Address=1, /Data=1, /Port0=1 (2) Read Port A (to clear CA1) (3) R/W=1, /Address=1, /Data=1, /Port0=0 (4) CA1=1->0? (5) Read data (clears CA1) (6) If more data, goto 4 (7) Return, A=number of bytes not successfully sent (0 on success) To read a packet: (1) R/W=1, /Address=1, /Data=1, /Port0=1 (2) Read Port A (to clear CA1) (3) R/W=1, /Address=1, /Data=1, /Port0=0 (4) CA1=1->0? (5) Read data (clears CA1) (6) If more data, goto 4 (7) Return, A=number of bytes not successfully sent (0 on success) This requires: (1) D0-D7 = Port A D0-D7 (2) R/W, GPIO Output (3) Wait/Ready, GPIO Output (4) /Address, /Data, /Port0, three GPIO Output (5) Port0 UART Ready, CA1 (6) Port0 System Performed, CA2 (7) UART IRQ, CB2 (8) Reset UART, GPIO Output So that fits the User Port (with CB2 jumpered in), as it is 8 data lines in Port A, the available CA1,CA2, CB2, and 6 Port B GPIO, when six are available. As far as potential compatibility with an EPP interface, that's out, but as far as potential compatibility with a device that is designed to work over an EPP protocol but know that there may be a UART using the same port ... that's feasible, all it takes is allocating it's pseudo registers to $10-$1F, and having it ignore any reads or writes directed to any lower registers. For that: Data0-Data7 = EPP Data0-Data7 R/W=EPP R/W output Wait/Ready = EPP Wait/Ready input /Address = EPP /Address output /Data = EPP /Data output /Reset UART = EPP /Reset /Interrupt = /CB2 = EPP Interupt /Port0 = EPP Not Used /CA1 = EPP Not Used /CA2 = EPP Not Used
  20. Yes, the MAX3100, that's the one that is still available in through hole packaging and 5v power. AFAICT, all of the later ones in the series are only 3.3v, surface mount. Mouser carries that one ... Digikey doesn't carry it ... they have 95 of the $7 (Q1) in stock, and list a six week factory lead time for larger orders.
  21. Aren't SPI2, 4 & 8 primarily for memory? A single SPI using a single shift register would, of course, need a shift register with daisychain serial output, which can act as a Serial In/Out, Parallel Read/Write shift register, which isn't what the 6522 provides. That's why you need two 6522's to implement a hardware SPI, as well as a quad XOR if you want to get all four modes. But some SPI devices are half-synchronous, and generate a 0 when receiving data or ignore the data output when writing data. Others only generate a 0 when receiving data in a normal state or a 1 when in an abnormal state, so they only send #0 or #$FF when receiving data. For those devices, a R/W control line to switch the 6522 serial shift register between MOSI and MISO and to switch MISO to ALERT when in write mode would allow a single 6522 serial shift register to talk to those half-synchronous SPI devices. And, obviously, if there was a SIPO shift register (eg, 74HC595) on the User Port, then with it tied to the correct clock and latch pin in the 6522, that would enable a hardware SPI, using the single shot byte output of the VIA serial shift register and the clock pulse output tied to the clock input of the serial shift register. That works for a User Port device that uses Port A as the parallel read or write, but only really works on the motherboard if there is a spare select pin in the built-in I/O select space. Plus a generic SPI output needs to be set up to handle all four modes ... a dedicated interface to a MAX3100 only needs to handle the mode of the MAX3100, so possibly a four IC dongle or expansion card, with 74HC595, a quad inverter, a MAX3100 and a RS232C level converter (which can be simpler than the MAX charge pump chip on an expansion card which has +/-12v power available).
  22. The CA2 handshake is not "get ready, an action is coming", it's a signal that the a read or write of the Port A has occurred, and the two handshakes are built around that. If CA2 is in handshake mode, after a read or a write of Port A, CA2 goes low and stays low for until C1 receives it's clock edge. So in handshake mode, CA2 is "Data Ready" when writing data to Port A ... this goes low until "Data Taken" is received on CA1. In read mode, CA1 is "Data Ready" FROM the other device, and CA2 is "data taken" signaled to the other side, so it goes high when a "Data Ready" is received on CA1 and then goes low when the data has been read. In pulse mode, CA2 goes low for one clock cycle after the read or write of PortA, rather than going high when CA1 detects the next edge. So if you have a 6522 on both sides, you connect CA1.system1 to CA2.system2 and CA2.system1 to CA1.system2. So if you want a master/slave set-up, you'd have DIFFERENT lines that signal "get ready for a write" or "get ready for a read" (R/W in EPP), and "I want to do a data packet transfer", (/DATA in EPP), and leave R/W and /DATA in their state while CA1 and CA2 handshake the individual byte transfers. When /DATA goes high, then then packet has been transferred. A second signal would be used for STATUS (when R/W=1) and SETUP (when R/W=0), because those are individual byte transfers, not packets. So in /Data mode, the loop only monitors "data taken" in writes and "data ready" in reads and the opposite of the pair is handled automatically when the write or the read of the port takes place. As maximum throughput, if the slave device is accepting or generating the data as fast as the 6522 in the master device, that throughput is a bit over half the throughput of an internal 65c02 block memory copy. Now, with CA2 being used as the data ready line for writing data packets and the data taken line for reading data packets, it can't be used as the independent IRQ, so PB2 would be used as independent IRQ ... this takes the interface away from the parallel port interface, as PB2 would have to be jumpered through on a line that would be ground for a Centronics interface. Yes. The Interrupt Flag register [IFR] is "1=happened, 0=didn't happen". So if CA1/CB1 is set to detect a negative edge, we can see whether a negative edge has happened since the last read or write of Port A. Or, if CA2/CB2 is set up in a negative edge independent interrupt mode, we can see whether a negative edge has happened since the last time that bit in the IFR was set to 0. Each bit in the IFR can be set to trigger IRQ or not, based on whether the corresponding bit in the Interrupt Enable register [IER] is 1 or 0. And the high bit in the IFR is high if any bit set to generate an IRQ is presently high, so when processing an IRQ, if you load the IFR, you can BPL out if that is not the source of an uncleared Interrupt or BMI out to the interrupt processor. If you have a 7 vector jump table for the interrupt handlers for the independent sources of an interrupt in the 6522, you can: LDA VIAx_IFR BPL ++ AND VIAx_IER LDX #$0C - LSR BCC + PHA PHX JMP (VIAx_Interrupt,X) PLX PLA + DEX DEX BPL - ++ RTS
  23. If it's that SPI UART that is available in the +5v through pin package, I'm all in favor, whether it is because there is ONE free pin on Vera to enable a second SPI select (though in that case, it wouldn't be USING the +5v / through pin version, but I'd still want to be using that one, due to the expansion slot possibilities for re-using the same driver code) ... ... or because something is done to provide an SPI bus on the motherboard ... in the second case, bringing out SCLK, MOSI and MISO through block jumpers on the User Port would make the CX16 User Port a distinct step up from the C64 User Port. But I've already made it clear the throughput available on a SPI UART is fine by me, I guess the question is directed to everybody else.
  24. It's true that a lot of people have come on board SINCE the topic was talked to death. For me, the only anachronistic element as far as the 8bit era is using the more refined PS/2 connectors as opposed to the bigger AT keyboard connector, and I'm perfectly fine with that ... that's the kind of "smoothing out the rough edges" that was discussed in Dream Computer 1. AFAIU, the digital side of the AT / PS/2 keyboard interface was contemporaneous with the height of the C64 / 8bit Atari era. As far as DE-9 joystick ports, we now have two options ... a dongle with a shift register inside that reads the state of the DE-9 port when the select line is pulsed low, and a direct wire through pair of DE-9 joystick ports on the User Port ... which would be program your own interface in true User-Port-Joystick-Expansion style.
  25. To confirm, this "most of" means that PB6 & PB7 are in use?
  • Create New...

Important Information

Please review our Terms of Use