|
Post by dshadoff on Feb 17, 2021 15:11:55 GMT
Now nobody that I know of has actually bothered (myself included) to write something for the PCE+TED2 that communicates back to the connected PC, but that only means that nobody has actually had a reason to do so, yet. While it *might* not work, I really can't imagine why it wouldn't when KRIKzz actually bothered to document it. OK, this is in line with my understanding. The previous note made it sound like 2-way communication had been in use for years. As for Zmodem, I have sources for Arduino which can probably be converted, but I suspect it may take up a bunch of space on the card. One thing which bothers me a bit is the fact that after all these years, we're still just transferring raw blocks of data, and need to specify during each transfer where it should be loaded. Tedious, although occasionally necessary. Since most files of that era - disk, cassette, and Intel- and Motorola-format ROM files - generally include address or offset information along with the data itself, it might be nice to finally start using such information in our transfers. For one thing, it would indicate where zmodem should silently stuff the data - and additionally, it could be discontinuous. About the PC boards, I've sent off the designs to be fabbed; there could be a minor hitch/delay with the USB connectors because I designed a footprint based on the datasheet, but it looked like it didn't perfectly line up on their gerber viewer. Hopefully this can be assessed/corrected by the operator during the review stage.
|
|
|
Post by elmer on Feb 19, 2021 17:17:44 GMT
Since most files of that era - disk, cassette, and Intel- and Motorola-format ROM files - generally include address or offset information along with the data itself, it might be nice to finally start using such information in our transfers. For one thing, it would indicate where zmodem should silently stuff the data - and additionally, it could be discontinuous. Once you've got the transfer capability, it is entirely up to you how you process the data transferred through that link. There is no reason why you couldn't decide to process the data received by the Z-MODEM protocol as an Intel HEX stream if you wished, and support discontinuous loading. The main trick (from my POV) is to support some simple-to-operate scheme, where you don't have to spend months/years writing a robust Windows/Linux application in order to communicate with the PC Engine. That is why I like the idea of running the TERATERM or MINICOM, with their built-in support for, and automatic detection of, Z-MODEM transfers. About the PC boards, I've sent off the designs to be fabbed; there could be a minor hitch/delay with the USB connectors because I designed a footprint based on the datasheet, but it looked like it didn't perfectly line up on their gerber viewer. Hopefully this can be assessed/corrected by the operator during the review stage. Cool! Yeah, the EasyEDA library isn't perfect, I had to rotate the RAM chip's orientation in the PickAndPlace file that it output, because it didn't match the Gerber view on the website when placing the order for the boards.
|
|
|
Post by dshadoff on Feb 19, 2021 17:53:25 GMT
While I won't argue that ZMODEM will make transfers easier (as a user), looking into ZMODEM (or anything from that era), the transfer techniques were built for files which had already been generated, as the filesize needs to be known at the start of the transfer.
This makes such transfers more difficult (as a programmer), unless there is a side-location where the file is created and staged into, prior to initiating the ZMODEM transfer. This too can be done - but it involves creating temporary (or permanent) storage for the PC Engine as a staging area (a further complication). Or a side processor to handle things like this (which was another idea I had previously).
I agree with the goal, but the solution is perhaps complicated... so I think there will be intermediate steps before that goal is achieved.
|
|
|
Post by elmer on Feb 19, 2021 19:19:32 GMT
I agree with the goal, but the solution is perhaps complicated... so I think there will be intermediate steps before that goal is achieved. I am having a hard time seeing the problem with my current understanding of what you wish to achieve. If you transfer from the PC to the PCE, then you already know the filesize. If you are creating and using a non-standard file format ... then you still know the filesize. If you tansfer from the PCE to the PC, then it is in response to some user command in PCEMON, or to some program-generated action ... in which case you already know (or can easily calculate) the filesize. No extra buffer space should be needed beyond one packet, since I don't believe that you would ever have to deal with out-of-order packets. I am rather assuming that the ZMODEM code on the PCE side would be modified from the stock code to directly support whatever discontiguous transfer that you feel is needed, which is rather the point in implementing your own version, even if it is just a small modification to the original. The PC side of the transfer wouldn't care, since it just handles the transfer as a single block of data going into a single file. Unless I am much mistaken, you could achieve everything that you want to achieve just by intercepting the PCE ZMODEM's read-byte-from-packet and write-byte-to-packet functions, and then turning them into subroutines. Now maybe I'm wrong, but I would be rather shocked if something couldn't be made to work, and it wouldn't need an extra processor, or more than 1 bank of RAM. On the TED2 you already have an extra 1MB-3MB of RAM available to use, and with your new board, there is extra memory for folks that don't already have a TED2. Is there some circumstance that you are thinking of where you want to transfer a binary (i.e. unreadable) stream of data that doesn't have a fixed length? Even if you are thinking of recording a stream of joystick presses, where the length of the data really isn't known, so that you can create a "demo mode" for a game, then you just have to support XMODEM transfer as well as ZMODEM transfer. The only difference from TERATERM or MINICOM's POV is that you would have to manually initiate the transfer on the PC side of things. Am I being an idiot and missing something obvious?
|
|
|
Post by dshadoff on Feb 19, 2021 22:33:53 GMT
First, I would like to say that this hardware setup is just one step along the evolutionary path I am thinking about. The final state I have in mind is substantially different.
Zmodem is a nice way to overcome an inconvenience, but it is not the only way to overcome that inconvenience (and is not an end-goal in and of itself, for me). It has hurdles to overcome, and the solutions then have their own hurdles... I agree that it's solvable - but I think any solution would be a fair investment in effort and would probably still end up being kind of "hacky" in order to make it work. For that amount of effort, I'd prefer to both (a) wait-and-see whether this is the biggest/only inconvenience which needs to be overcome, and (b) perhaps invest in my longer-term goal which doesn't have the inconvenience to begin with.
In any case, in answer to your questions on how I would use it, PC->PCE transfers are easy; turn off echo and it doesn't disrupt the transfer. PCEmon already handles this well.
However, PCE->PC transfers could be: (a) fixed-size blocks of data (b) disassembly outputs (where binary size is know, but not # lines or # characters per line on text output) (c) free-running logging and so on.
If these could be stored on SDCard (for example), they could be "of known size" prior to transfer. But if they were stored on a separate processor (say, an Arduino), already-working code code be dropped into place rather than rewriting zmodem into 6280 assembler. And if this output was a different I/O channel than the one USB used for terminal access, it wouldn't need to interfere with the main terminal session which you don't want interrupted.
I don't have any problem with having a second I/O port for example - one for command and one for data, for example.
|
|
|
Post by elmer on Feb 20, 2021 16:57:52 GMT
First, I would like to say that this hardware setup is just one step along the evolutionary path I am thinking about. The final state I have in mind is substantially different. OK, that's neat, so you have a "PLAN" for something really cool, and I guess that I am missing the point on where you want to go with all of this. It sounds like you really want to add some Arduino hardware onto your board, while I tend to favor using software solutions wherever possible. Of course, software can only take you so far, and sometimes you do really need a hardware solution.
|
|
|
Post by dshadoff on Feb 20, 2021 17:55:34 GMT
No, you're not missing the point on the long goal... I haven't mentioned what it is yet. (I want to make a little more progress first.) But I think you'll be interested when I've got something going, particularly if you're interested already. The short-term goal is to bring PC-E and PC closer together and become more familiar with communication at the electrical level, including how to verify the timings/sequences of signals which are not yet 100% clear (such as, when does SCSI status/acknowledgement get returned to the calling program - instantly, or after a small delay, or only after data is ready ?). Another short-term goal is to remove some of the current inconveniences in developing on the system. For example, let's say as part of a translation project, I want to see where various CDROM sectors are loaded into memory (and whether loaded into ADPCM, RAM, or VRAM). I can - and did - build this logging into Mednafen, but it was a pain in the neck going into that code. And even then, it was only logged into its little weird "walled garden" where you could see it on-screen, but couldn't log it to a file for later use. But with the FT245 chip, I can just hack the system card slightly, and get that logging sent to the PC where I can capture it, with less-than-millisecond delay incurred on the hardware. Afterward, the data could be sorted and used. In getting the PC and PCE to talk to each other better, the challenge (up until now) has been that the glue logic (i.e. address decode/latching/etc. hardware) on the PCE side has been unwieldy and has required many parts, requiring significant effort to make even a single unit. This has been changing over the past several years, as PC boards become cheaper, design software is more accessible, and so on. Right now, all the logic on these initial "tinkertoy" boards is 5V for simplicity, and as such, power consumption is a concern. The GAL chips on both of these boards - even though they have been selected for the lowest possible power consumption - will take about 100mA collectively, plus another 60-100mA for the other circuitry. While this is likely not ultimately a problem, it's not ideal either... a 3.3V solution is ultimately the solution, but it will multiply the number of parts due to the number of level-shifters required. Right now, only some of the address lines are decoded (for example, the entire $FF:$1C00 range is in use for the USB), so that's also not sustainable. And of course, exposed contacts are probably not where we want to be with development hardware. So, while some people could benefit from these, I don't consider them to be end-state, but rather steps along the way. Since pre-fab building blocks exist in the non-PCE world which do some very interesting things (for example, zmodem on Arduino) ... I'd prefer to make use of them where possible, in order to reduce development time. Think of it as scaffolding... not part of the end product, but assist in development - and may actually be replaced by PCE implementations.
|
|
|
Post by dshadoff on Feb 27, 2021 15:27:27 GMT
OK, today I got the USB adapter working. It's memory-mapped at $FF:$1C00 for data, and $FF:$1C01 for status, and it's quite fast. For comparison, I've been using PCEmon at 19200bps, which is about 2K bytes/second - this is fine for text, since it's faster than you can read it - but it's quite slow when transferring files - extracting 256KB of data (smallish HuCard, or roughly a savestate, based on Chris' PCEmon process), it's about 2 full minutes. The USB interface is closer to 100 kilobytes per second - making the same extraction about 2 seconds. Unfortunately, this design wasn't perfect first time, and needed bodge wires - so I'll be adjusting the design and ordering another round of boards just to be sure. What would you use this speed of communication for ? I am currently thinking (besides PCEmon): 1) Instrument System Card to spit out a log of when data is loaded from CDROM, to log a cross-reference of data sector-to-memory mapping. This will help with translation projects. 2) I was toying with the idea of having a system like the TRS-80 Colour Computer's "DriveWire" - where a special version of the system card redirects certain requests through the USB port to a PC, where a server responds. 100KB/s is close to CDROM speed, and this might help game development (or translation) where small adjustments are made - the PC host would just serve up the new sector at the next request. (This only works if the data remains in the same sectors when it changes). Might be nice for a more fluid cycle-time on small adjustments.
|
|
|
Post by dshadoff on Feb 27, 2021 16:30:53 GMT
...But wait, there's more. Inspired by the Raspberry Pi GPIO extenders, I built a thing for breadboarding. (Note: the Raspberry Pi extenders have many wires connected to ground, so a PCE-specific board was needed... but the ribbon cable was salvageable). Seriously, I have wanted a convenient way to break out the signals for a long time. ...And now, the "whole family" all stacked up:
|
|
|
Post by dshadoff on Feb 28, 2021 1:24:18 GMT
|
|
|
Post by elmer on Mar 1, 2021 19:57:57 GMT
OK, today I got the USB adapter working. Woohoo, congratulations! BTW ... I see from your photo that your Turbo Everdrive doesn't have the USB option installed, and I seem to remember from the dim-and-distant past that you were thinking about having an attempt at retrofitting the chip and connector onto your TED. I guess that you don't need it now, but was there a reason that you didn't go through with installing the chip/connector?
|
|
|
Post by dshadoff on Mar 1, 2021 21:54:30 GMT
I have two Everdrives... I installed one USB chip/connector - on one with no plastic shell (not in this picture). There isn't enough clearance between the board and the plastic shell to accommodate the USB connector.
|
|
woodcan
Deep Blooper
Posts: 9
Fave PCE Shooter: Star Parodier
Fave PCE Platformer: Bonk's Adventure
|
Post by woodcan on Mar 2, 2021 18:34:33 GMT
As a hardware guy this looks neat. I'm going to set a mental reminder to come back here and read through your posts dshadoff
|
|
|
Post by dshadoff on Mar 2, 2021 23:18:15 GMT
Well, I found a part which is screaming out to be incorporated into a future version of the memory card... www.digikey.ca/en/products/detail/cypress-semiconductor-corp/CY62167G-45ZXI/5402829...a 5V static RAM big enough to hold the PC Engine's entire address space, at a very reasonable price (probably overstock). It might be interesting to implement a mapper in programmable logic which: - places the Flash memory in Bank $00 at startup (to be relocated later) - allows each bank to be programmable - writable RAM/RAM with write disabled (pseduo-ROM)/Flash/unmapped
|
|
|
Post by dshadoff on Mar 14, 2021 1:26:13 GMT
I created a GitHub repository for System Card patches - I am thinking initially that they will be centered around these articles of hardware. github.com/dshadoff/PCE_SystemCard_PatchesThe first such patch catches calls to CD_READ, and sends data about the request out the HuUSB port to a computer which can log these requests. Initial thinking is that by playing through a game, we can get a map of which sectors are loaded at what points, into which banks/locations of memory. I don't think it's quite substantial enough for this usage yet, but whatever is missing should become clear through use. I know that not every game accesses the CDROM unit via the System Card; I also started thinking about using an FPGA to intercept accesses to the CDROM-specific memory locations...
|
|