|
Post by dshadoff on Feb 13, 2021 23:57:22 GMT
I've wanted to develop for the PC Engine - as close to the actual machine as possible - since the beginning. Emulators have come close, but there are still so many deficiencies in even the best of them, in terms of cycle-accuracy, or colour presentation, etc. Testing on a real machine requires a real machine, interface hardware to the development system, and some diagnostic tools. So, I started building out some hardware to assist in this... I have designed: - a HuCard PC Board which breaks out the various signals to a header on the face of the card
- a memory card which adds:
- Flash in banks $90-$9F (unused by commercial hardware) for a monitor program
- Static RAM in banks $B0-$EF for temporary storage and testing
[/ul] These cards are stackable onto an extensible bus. I have also published the plans here: github.com/dshadoff/PCE_HuBus_ProjectsHere's a picture:
|
|
|
Post by gredler on Feb 14, 2021 5:02:36 GMT
This is amazing!
|
|
|
Post by turboxray on Feb 14, 2021 22:08:04 GMT
I've wanted to develop for the PC Engine - as close to the actual machine as possible - since the beginning. Emulators have come close, but there are still so many deficiencies in even the best of them, in terms of cycle-accuracy, or colour presentation, etc. Testing on a real machine requires a real machine, interface hardware to the development system, and some diagnostic tools. So, I started building out some hardware to assist in this... I have designed: - a HuCard PC Board which breaks out the various signals to a header on the face of the card
- a memory card which adds:
- Flash in banks $90-$9F (unused by commercial hardware) for a monitor program
- Static RAM in banks $B0-$EF for temporary storage and testing
[/ul] These cards are stackable onto an extensible bus. I have also published the plans here: github.com/dshadoff/PCE_HuBus_ProjectsHere's a picture: Attachment Deleted[/quote]About the hucard connectors... any idea where Analogue and PolyMega are getting their hucard connectors from???
|
|
|
Post by dshadoff on Feb 14, 2021 23:07:12 GMT
No idea... but I guess somebody in the world has made some, so mabe some form of HuCard connector could be obtained in the market (perhaps Shenzhen though).
|
|
|
Post by DarkKobold on Feb 14, 2021 23:56:38 GMT
I have no idea what this does or how it helps you. Is it away of stress testing the PCE? Finding edge cases to improve FPGA simulations?
|
|
|
Post by dshadoff on Feb 15, 2021 0:23:16 GMT
It's extra memory for use with debugging and so on. For example, the Flash could hold PCEmon.
PCEmon often feels like you're competing with the game itself for memory, so this also implements a bunch of RAM. ...So much RAM, that it could hold a savestate of a CDROM game (SuperCD RAM + CD RAM + scratch RAM + ADPCM RAM + BRAM + VRAM + palette + register values).
It might not be much use for people who never touch assembler or debug at that level though. My thinking is that I would use it to debug individual subroutines by downloading them, and for example single-stepping and feeding some values (sometimes you might need to force certain values), etc.
|
|
DutchDimension
Punkic Cyborg
Posts: 122
Homebrew skills: Pixel, 2D and 3D art
Fave PCE Shooter: Override
Fave PCE Platformer: Mizbak's Adventure
Fave PCE Game Overall: Too many to choose from
Fave PCE RPG: Ys series
|
Post by DutchDimension on Feb 15, 2021 7:13:36 GMT
Very cool!
So what do you intend to develop on the PC-Engine software wise?
|
|
|
Post by dshadoff on Feb 15, 2021 17:37:54 GMT
At the moment, I'm just building some preliminary tools, and eventually will create something for the rear connector, involving level-shift and perhaps an FPGA. First and foremost, PC-to-PCE communications needs to be improved, as that has always been a weak point for development. But I think that's getting close.
While everybody seems happy to develop graphics on their computers, I feel that it would be better to see them on the real machine, because I'm still not convinced that we have an adequate system for simulating the colours (especially darker shades and dither patterns).
Playback of music and/or ADPCM is also an area where there could be some disagreement on whether current tools are accurate.
And I also want to verify some hardware behaviours, like: - what are the actual initialization values of the video registers ? - when SCSI commands are sent to the CDROM, at what point are the status values sent back ? etc.
After tools are available (not in the immediate future), I will probably be looking at existing games in more detail, examining their techniques, and perhaps altering them (such as translations).
So, basically a lot of nerding out.
|
|
|
Post by gredler on Feb 15, 2021 19:47:35 GMT
While everybody seems happy to develop graphics on their computers, I feel that it would be better to see them on the real machine, because I'm still not convinced that we have an adequate system for simulating the colours (especially darker shades and dither patterns).I feel so lucky to have one of the USB TED 2.5's, along with the turbo-usb2.exe I am able to launch the game directly to my coregrafx or turboexpress for checking colors on TV via real hardware. I do this so often I wrote a little build script that checks for an existing rom and deletes it if it exists, builds the rom with DK's build script, then loads the output rom to turbo-usb2.exe. I then mapped that script to a hotkey in VS Code. I have to press the reset button on the ted to go back to the main menu before builds, but the system is within arms reach, so I press that button then hit CTRL+ALT+R and my saved art changes build into a new rom and show up on the system in about 5~ seconds. My build script also is setup to load to bizhawk depending on which I have uncommented at the time. I love my workflow, but having a way to create breakpoints to see vram + palettes loaded would be crazy Here is my build script incase it's helpful to anyone with a ted2 2.5 usb, @echo off
rem ***************************************************************************
:: Build and Run Script by Greg Brant 10/23/2020
:: Delete main.pce, run build.cmd, then launch in either local emulator
:: or feed rom into turbo-usb2.exe to send the game to a ted2 usb connection
rem ***************************************************************************
echo Starting script
::pause
echo
:: delete old rom to prevent looking and unchanged game
echo Checking for previous build
if exist main.pce (echo main.pce found -- Deleteing old ROM) else (echo No old rom found)
if exist main.pce del main.pce
echo Old ROM purged
:: pause
echo
:: Build game
echo Starting Build
call build.cmd
if errorlevel 1 echo BUILD FAILED: Inspect log for details!
echo Build complete successfully
TIMEOUT 2
:: Launch game TODO: Make script not get to this point if build fails
:build-successfully-completed
echo Launching game
:: launch in emulator
:: start emuhawk c:\huc\Catastrophy\main.pce
:: launch on hardware via turbo everdrive 2.0 w/ usb connection
call turbo-usb2.exe c:\huc\Catastrophy\main.pce
echo Build done at:
time /T
|
|
|
Post by elmer on Feb 16, 2021 17:10:51 GMT
Testing on a real machine requires a real machine, interface hardware to the development system, and some diagnostic tools. Cool stuff, it's great to see some of those empty areas of memory get put to some good use! Yep, real hardware can't be beat for some testing, especially graphics and the really timing-sensitive stuff! But honestly, IMHO software emulators are far better for *most* of the run-of-the-mill parts of program development and debugging, for the same reasons that folks used to use frighteningly-expensive in-circuit emulators in the past. First and foremost, PC-to-PCE communications needs to be improved, as that has always been a weak point for development. But I think that's getting close. Close? As Gredler points out, some of us with a TED2 have had fast 2-way communications between a PC and the PCE for over 5 years now. Since you're designing your own board, I would urge you to implement the same type of solution with an FTDI FT245RL.
|
|
|
Post by dshadoff on Feb 16, 2021 18:10:05 GMT
Yes, it will be a FT245RL.
When I say 'close'... - overall approach is clear - signal timing and protocol check was done last week - circuit design is 90% complete (just need to apply passives) - board layout is 85% complete - CPLD programming is done, and ready for validation - modifications to PCEmon to accommodate are complete
I think I can complete the remaining pieces tonight and submit a design to JLCPCB for SMD assembly of all parts but the 2x20 connector. If I'm lucky, I'll get it back at the end of next week.
...And then of course, test could take anywhere from 5 minutes to a few weeks (plus iterations on the design...). But I'm optimistic.
|
|
|
Post by elmer on Feb 16, 2021 22:14:57 GMT
I think I can complete the remaining pieces tonight and submit a design to JLCPCB for SMD assembly of all parts but the 2x20 connector. If I'm lucky, I'll get it back at the end of next week. ...And then of course, test could take anywhere from 5 minutes to a few weeks (plus iterations on the design...). But I'm optimistic. Oooooooooooohhhhhh, *that* kind of "close" ... yippee, congratulations! I'll cross my fingers and hope that it works, because when it does, you know that I'll be begging you for some more board-layout advice.
|
|
|
Post by dshadoff on Feb 17, 2021 0:24:38 GMT
As Gredler points out, some of us with a TED2 have had fast 2-way communications between a PC and the PCE for over 5 years now. I was aware of the fast, 1-way download of HuCards via Krikzz's loader, but I don't think I ever heard of any other transfers - especially 2-way. Could you elaborate a bit on this ?
|
|
|
Post by elmer on Feb 17, 2021 3:02:38 GMT
Could you elaborate a bit on this ? Well, USB itself and that chip in particular are both 2-way communications paths, as are the Virtual COM drivers for Windows/Linux. KRIKzz's TED2 documentation, and my TED2.INC header file, show how to both send and receive data on the USB link. KRIKzz's TURBOUSB.EXE can detect whether it is successfully communicating with the TED2, which rather implies that 2-way communication is working properly. 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. From my POV, I haven't bothered yet because a 2-way link isn't important to me until I can send files seamlessly down that link without disturbing any text that I want to see. For me, that means using TERATERM, PuTTY or Minicom on the PC and being able to do Z-Modem transfer to/from the PCE. I don't have Z-Modem source code for the 6502/6280, and I haven't had the time/desire to write it yet. But TEOS already has the CRC tables and a 6280 disassembler included in it, waiting for that time to come.
|
|
|
Post by gredler on Feb 17, 2021 6:20:32 GMT
I probably should have elaborated clearer that my use of the ted2usb is purely for art workflow to speed iteration for checking the art on real hardware. For any debugging I use emulator to see vram, frame timing, loaded palette, etc
|
|