Jump to content

BruceMcF

Members
  • Content Count

    111
  • Joined

  • Last visited

  • Days Won

    2

BruceMcF last won the day on August 8

BruceMcF had the most liked content!

Community Reputation

58 Excellent

Recent Profile Visitors

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. If they were the distributor, they would obviously be much less hesitant.
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...

Important Information

Please review our Terms of Use