Project: USB connected downloader tool for PS1 development

The PAL is quite simple - this is the logic I'm using. The ROM mapping might be a bit wrong (256k ROMs don't work, but 128k ones do)

PAR_SW is the on/off switch on the board and PSX_STB is a signal that's asserted when there is data to read on the comms link.

--
-- 0x1F000000 - 0x1F01FFFF First half of flash ROM (R/W)
-- 0x1F020010 Returns STB bit in D0 (data available) (R)
-- 0x1F020018 Returns status of switch in PSX_DATA(0) (R)
-- 0x1F040000 - 0x1F05FFFF Second half of flash ROM (R/W)
-- 0x1F060000 Read incoming data byte (R)
-- 0x1F060008 Write response byte (W)
--
-- Access to Flash ROM - note that CS/ is tied to ground on the PCB
FLASH_A17 <= PSX_A18;
FLASH_OE <= NOT (NOT PSX_CS and NOT PSX_RD and NOT PSX_A17);
FLASH_WR <= NOT (NOT PSX_CS and NOT PSX_WR0 and NOT PSX_A17);


-- Other read accesses
PSX_DATA(0) <= PAR_SW when (NOT PSX_CS AND NOT PSX_RD AND PSX_A17 AND not PSX_A18 and PSX_A4 and PSX_A3) = '1' else 'Z'; -- Switch
PSX_DATA(0) <= PSX_STB when (NOT PSX_CS AND NOT PSX_RD AND PSX_A17 AND not PSX_A18 and PSX_A4 and NOT PSX_A3) = '1' else 'Z'; -- STB bit
PSX_DATA <= psx_indata when (NOT PSX_CS AND NOT PSX_RD AND PSX_A17 and PSX_A18 AND NOT PSX_A4 and NOT PSX_A3) = '1' else "ZZZZZZZZ"; -- Data port


-- Decode the link register write condition
psx_wdata <= (NOT PSX_CS AND NOT PSX_WR0 AND PSX_A17 and PSX_A18 and NOT PSX_A4 and PSX_A3);


Just in case you're interested, here is a little video - sorry for using Youku, but uploading stuff to youtube is a pain in China because you have to use a VPN, and it was really slow today...

http://v.youku.com/v_show/id_XNTk3OTc5OTY4.html

 

So it looks like you got it sorted out to where is connecting up to pc with little issues besides sometimes hanging on the "PC is in Control" message which can be reset to go back into the menu. So what is on the board component wise to get this up and running? Any idea when you will release the design?

 

Yeah, it's basically working - the biggest issue at the moment (although it didn't happen during that video) is the one I mentioned above - Caetla doesn't send an ack pulse if the first character written during the command phase is not the "C" it's expecting - I have put a timer into the logic so that if it spends more than 250ms in any state except the one where it's waiting for a character from the PC then it resets the state machine. This gets around the problem of the converter locking up, but invariably causes the operation to fail with either a protocol error or a timeout - both of which are fatal as far as catflap is concerned.

My current line of thought is to change the protocol between the PC and the converter - right now, it's just sending bytes in a completely dumb manner, and I can't signal any abnormal conditions because there is just one data channel and there are no illegal bit patterns. There are two methods that come to mind:

1) Use an escape character on the link, and insert the OOB data using that - of course, if you have a block filled with the escape character then it will become twice as long, but this shouldn't happen that often if the character is well chosen.
2) Used a mixed data stream with metadata interleaved with the actual data - something like this:

<Send>'C'
<Expect>'d'
<Send>'L'
<Expect>'o'
<Send>0x01
<Send>0x02
<Read><1 byte>

The problem with this is that it will require fairly heavy modifications to the control software, since basically it's sending the protocol information along with the actual data - but it would make the actual data transfers a lot quicker since the converter would now know which bytes are not relevant. Right now, when I downloaded that 128KB BIOS, the PC had to send 128KB of dummy data just to generate the handshakes. Right now, I'm tending towards this approach.

I'm not going to have a final BOM until the design is complete - but it's going to be something like this:

Flash: 29EE020
Regulator: 78M05 (may not be necessary if we use a 3.3V flash)
CPLD: Havent decided yet
USB: FT245
Clock Xtal: To suit CPLD (or use the PSX clock...)

The current CPLD is way oversized for the application - it's using < 20% of the device even with the LCD in use, and I expect that the logic driving the LCD is substantially larger than the stuff doing the transfers. OK, I just checked it - with the LCD removed, it's using 46LEs (so 4% of the chip). The smallest MAX II is 240LEs, so it would easily fit in that.

My plan was to do an initial release as soon as it was working well enough for me to start laying out the PCB - right now, there is stuff in there that I would be embarrassed to show anyone

 

Wouldn't it be simpler in the long run to build a new rom and new logic so it would work without having to constraint the new design to old logic and programming? I know some new software or a hack of old software would then be required, unfortunately I know very little of PSX programming besides making cheat codes to help out.

 

EPM3032A/EPM3064A

I don't see why you need more than an address decoder and buffer for the flags. It should be trivial to modify the program to directly interface with the FIFO.

 

Probably yes - the basic problem is that there is a whole bunch of stuff built into Caetla (especially the debugging features) that interact with the system in ways that I don't understand. Implementing the basic functions wouldn't take too long, but getting it to the point where it had the same level of functions as the existing code would likely take way too long since I'm working on a spare time basis.

The other thing was that I was trying to develop something that could be used in two different ways - either as a complete cart replacement or as an interface board that connected to the comms link connector on a existing AR cart. This is also the reason I am being so anal about retaining the existing hardware interface protocol despite its flaws - because if you are connecting to an existing cart you are going to have to use it anyway.

Those FLEX devices are very nice for implementing glue logic, but they basically suck for even moderately complex state machine designs - firstly because the fan in on each logic cell is quite limited and you end up having to borrow pterms from adjacent cells and secondly because the feedback paths around the register are far more limited than in the MAX series. I personally prefer the XC9536/72XL - slightly slower, but also cheaper and has a few extra macrocells.

But you're absolutely right - if I was doing a clean sheet design it would be much better to just hook the USB chip to the bus and drive it directly, it would be simpler and give you better performance. However, as I mentioned above, one of the design aims was to make this compatible with existing carts hence retaining the protocol. I also have an aversion to binary patches based on working for too long in environments where things like that were Not Acceptable :smile-new:

Having said that, I will admit that I did have a look at the Caetla code and it would be quite easy to patch - there are basically 4 routines - one that sends a byte, one that receives a byte, one that does both send and receive and a poll/non destructive read routine. Of course, you wind up having to do this for every ROM someone wants to use which gets old real quick...

 

How many BIOS really need supporting at once? Unless you're going to "wired-OR" the decoding for every device--perhaps not possible, a hacky select switch would be necessary or you'll end up with separate CPLD configurations anyway.

 

Presumably there would be exactly one hardware config, and you would patch the software to suit it, if you were taking that approach - but that still wouldn't get around the incompatibility problem with existing carts, which are physically constrained to use exactly the existing AR hardware interface and hence modifying the software won't win you anything.

In fact, the original idea was just to make an external format converter - something you could plug into the DB-25 on the back of the cart and run it from a USB port, and the replacement cart idea came later - but retaining that capability is the other reason I didn't want to change the basic protocol.

 

i remeber you told you work w/ ARM mcu - i doubt - that one of cheap arm mcu cant be as this converter between pc and AR. for example SAM3U : usb 2.0, dozens kbytes ram, 8-16 bit extrnal bus and many other GPIO. cost 3..5$

 

My plan was to use an embedded cpu with usb and I/o and either upload the embedded cpu code at run time or have it flashable. It would be a lazy design that just piggybacked onto an xplorer fx card. The xplorer were nicer because you just needed a standard pc parallel port, so I can still use my old laptop. I can't find the one flashed with caetla and I've not bothered flashing the one I'm using now because the xplorer has a lot of the same functionality built in already. I was even thinking about making the usb device figure out what it was connected to and do all the conversions so the pc software didn't need to know.

 

Doing that for an explorer would be a lot easier - one of the other nasty features of the original Action Replay comms link port is that under normal circumstances the host has to drive the bus with the last data read and then turn it around and read the response data based on the state of a external signal. The strobe duration is far too short to be handled in software, so you have to have external hardware to handle that. At least on the xplorer all the lines are either in or out and can connect to conventional GPIO pins. The bad thing about the xplorer protocol is that it's quite a bit slower since it clocks out the data in 2 (or possiblly 3?) bit chunks. But at least it doesn't have the dummy byte stuff that the AR is saddled with.

The other thing is that the Xplorer/Xploder seems very uncommon outside Europe - it was imported to the US, but I don't think it ever got any significant distribution.

Yeah, any of those little MCUs would be fine - I haven't used those Atmel parts (mostly ST and NXP), but they are all pretty similar. I think that Atmel chip has high speed USB, which is nice, but probably overkill for a PSX. The only annoying thing is that (as I mentioned above) you still need some external hardware to handle the comms link braindamage, which was the initial reason I liked the PLD + USB chip approach since you were going to need a PLD anyway.

 

AR has "pld" and 245 line buffer, so no need extra parts, only mcu. (it's my opinion). but another thing if y wanna make your own device/pcb.

 

In fact, that buffer is precisely _why_ you need external parts.

The problem is that when you write to the AR you put the data on the bus and set a strobe line high - but it's not latched anywhere, and gets read some time later when the code in the cart bothers to poll the STB line and read the input data. It then sends a reply byte, but this is also not latched - it's just driven onto the bus and the ACK line pulsed high. On the receive end, either a transparent latch driven by ACK or one working on the falling edge will work - but this has to be done in hardware, since the ACK line is basically one of the write strobes from the PC.

Effectively, it's this signal, just fed out to an external pin:

-- Decode the link register write condition
psx_wdata <= (NOT PSX_CS AND NOT PSX_WR0 AND PSX_A17 and PSX_A18 and NOT PSX_A4 and PSX_A3);

Since it's so short, there is no possibility of using software to reverse the port direction, since the signal will be long gone before you can process an interrupt - and you can't set the port to input in advance since you have no way of knowing when the cart has read the data. The primary design aim seems to have been to make the interface hardware on the cart as cheap as possible, even it that meant adding extra complexity to the other end.

 

you can use mcu's pin to gerate INTerrupt. and see if psx read data and/or set new to answer.
but your idea (cpld+ftdi) is good too.

 

The data valid time is only something like 100ns - even one of those Cortex M3 MCUs running in zero-wait state memory will only be able to execute 6-7 instructions in that time (and that's if they are all single cycle) - using a standard IRQ handler, the data would be gone while the CPU was in the process of saving registers. The only way I could see it working would be to use the FIQ handler and preload the registers in the shadow register bank with the necessary values so that you don't get any load stalls - but the timing still seems iffy to me...

 

i tryed imagine how AR worked in original w/ ISA board. i think it was include only couple logic ic's and all protocol was handled by pc.

anyway - i look forward for your idea, you plan make pcb?

 

The original board had a pair of 8-bit latches with tristate outputs and a PAL with some glue logic in it.

Basically, when you wrote to the board, it saved the data in one latch and set a flipflop that drove the STB line high - once STB went high, the contents of the latch were driven on the data bus.

When the PSX saw the STB signal, it read the incoming data, and then wrote a reply byte - which was driven out on the databus along with the ACK pulse - which both reset the flipflop that was gating the out data to the bus and drove the E input on the other latch, so at the end of the ACK pulse the out byte was latched. This pulse also set another flipflop that was used by the PC to see that there was response data available.

Yeah, it's a very simple protocol, but despite that it relies on the host end responding extremely quickly.

This is the part of the original "action.exe" that talked to the comms link card (there was some extra code there that handled an activity indicator and break key, but it's been removed for clarity.

DataPort = 0x330 (default)
StatusPort = 0x332 (default)

seg005:0030 Comms_SendGetChar proc far ; CODE XREF: sub_2275F+236p
seg005:0030 ; sub_2275F+243p ...
seg005:0030
seg005:0030 TempVal = byte ptr -1
seg005:0030 ByteToSend = byte ptr 6
seg005:0030
seg005:0030 push bp
seg005:0031 mov bp, sp
seg005:0033 sub sp, 2
seg005:003A mov dx, DataPort
seg005:003E mov al, [bp+ByteToSend]
seg005:0041 out dx, al
seg005:0042
seg005:0042 loc_226A2: ; CODE XREF: Comms_SendGetChar+7Dj
seg005:0042 mov dx, StatusPort
seg005:0046 in al, dx
seg005:0047 mov [bp+TempVal], al
seg005:00A9 loc_22709: ; CODE XREF: Comms_SendGetChar+72j
seg005:00A9 test [bp+TempVal], 1
seg005:00AD jnz short loc_226A2
seg005:00AF mov dx, DataPort
seg005:00B3 in al, dx
seg005:00B4 mov [bp+TempVal], al
seg005:00B7 mov al, [bp+TempVal]
seg005:00BA jmp short $+2
seg005:00BC leave
seg005:00BD retf
seg005:00BD Comms_SendGetChar endp

So really simple, but it relies on the hardware on the card latching things.

 

My point is that if you're going to support unmodified Xplorer/Xploder/etc software you'll need at least another hardware config. So the question is: is it better for people using this to apply a software patch to suit their preferences, or make them reconfigure the logic?

I think if you get rid of the CPLD the project instantly becomes more accessible to everyone.

 

Ah, OK - I guess we were talking at cross purposes - I have to admit that I hadn't put any thought into supporting the xplorer/xploder stuff (mostly because I don't have one around here to do any testing with) - but I seem to remember that the flash mapping is different (0x1F000000-0x1F03FFFF) and overlays the addresses that are used for the status ports on the PAR - so supporting both concurrently might be a problem.

I'm going to have to decide pretty soon how to proceed anyway - I've now reached the point where the (predictable) signal integrity issues with those long wires are causing debugging problems, so I'm going to have to make a board.

As far as the off-board converter is concerned, you could support the XP type carts just using the GPIO pins on pretty much any MCU - the PAR type comms link interface is a bit more of a problem because Datel decided to use such absurdly fast write timing, so I suspect some external support hardware would be needed there.

 

You just need to incorporate the freewing schematic in there (which is basically a comms card plugged into a pc parallel port instead of an isa slot).

http://www.psfake.com/PsxFiles

You could add two idc headers for a db25 cable, one for ar and one for xp. You might need a jumper or two to configure which mode it is (or not...)

If you wanted to build a card that only did one you just don't populate the parts for the unused one. You'll only need to design and manufacture one PCB.