Messages

[Localizations, Games, Apps, Docs / Re: Everdrive SDK / SD card IO]

I too had a problem using the later versions of huc and pceas

What problems? Best to try and get them addressed.

[Localizations, Games, Apps, Docs / Re: Xanadu I/II and other SCD translations]

The Turbo Everdrive has no ram on the card for the PCE to use. Krizz, the creator, has said as much. Though a new card from him could have lots of ram; we'll just have to wait and see.

If you could write to the flash from the PCE side directly it'd be at least possible to store some data in it temporarily but you'd not want to write to it as often as RAM. Some SPI code to interact with the SD card was released which could also be used but the same issues apply.

I was casually researching the idea of using a highend microcontroller to simulate a PCE HuCard. The issue is having one fast enough to do the simulation and enough GPIO pins. I read an article recently where a guy used am ARM Cortex-M4 based 168 MHz STM32F4 to simulate an original Gameboy's. The problem with the PCE is that it has too many pins and none of the commonly available boards I've looked at so far have enough GPIO pins and all the ways to expand them utilize I2C which I suspect would greatly slow their effective rates.

If we could get something like a Raspberry Pi with enough GPIO pins... it wouldn't require *too* much effort to create a rather badass all in one card which could be a ROM cart, emulate the ArcadeCard, emulate the system cards, the Games Express card, more RAM, etc.

But at that point... may as well modify an emulator to provide virtual hardware you need and just run it off to your TV.

[Localizations, Games, Apps, Docs / Re: CHIPCE-8: CHIP-8 interpreter for the PCE]

I'm interested. Yeah... CHIP-8 wasn't double buffered but it'd be interesting to try.

I'm currently using vsync handler to deal with the CHIP-8 timers[0].

Code Select Expand

void chip8_vsync_hook(void) __mapcall __irq
{
}

irq_add_vsync_handler(chip8_vsync_hook);
irq_enable_user(IRQ_VSYNC);

I'm now noticing there is IRQ_HSYNC but no irq_add_hsync_handler.

• https://github.com/trapexit/chipce8/blob/master/HuC/emulator.c#L77

[Localizations, Games, Apps, Docs / Re: CHIPCE-8: CHIP-8 interpreter for the PCE]

To reiterate:

For 64x32 at 1bit color (regular CHIP-8):
* Create 1 black tile and 1 white tile
* Set the VDC to 512 pixel mode
* Set the tilemap to 64x32
* When setting a pixel calculate the offset into the alternate BAT tilemap and set the tile appropriately.
* On vblank do a VRAM to VRAM DMA transfer from the alternate to main BAT
* On hblank modify BYR so that it displays (at 512x224) 7 rows of each tile (or... 512x224 = 8/x; x=3.5; best we could do to keep ratio is to have 4 rows per tile. I was trying to use the whole screen which is why I used 8x7)

For 128x64:
* Use on 8x8 tile as 2 2x1 SCHIP-8 pixels?
* Each nibble would be 0 or 1 and combined would point to one of 4 tiles. (not even necessary really, just use the first 2 bits)
* 64x64 tilemap
* Screen would be 512x224 so each SCHIP-8 pixel would be 4x2 (512x224 = 4/x; x ~= 2)


Now... is there a way to work around the hblank interrupt issue in HuC?

[Localizations, Games, Apps, Docs / Re: CHIPCE-8: CHIP-8 interpreter for the PCE]

The reason why I bring it up (writing to the tilemap as pixels, rather than writing to tiles themselves), is that you can do 128x128 @241 color bitmap mode on the SGX. On the PCE, it's 64x128 @ 241 colors, or 128x64 @ 16colors (these two modes as setup different from each other). Coupled with VDMA, you can have an alt map in vram to write to and use VDMA to copy it over during vblank - giving a free double buffer bitmap function. With XOR patterned tiles (which is what the tilemap write references), you could double those colors or more (XOR dithering for 512 pixel mode looks decently convincing to a solid color). The best thing, is that you're only writing to the tilemap (or tilemap buffer in vram) with a fast single or double byte write for 1 or 2 pixels (depends on the setup you use). It's pretty fast.

I understand the concept. I originally wanted to do something like that but I'm not following how I can display the whole 64x32 or 128x64 tile map.

[Localizations, Games, Apps, Docs / Re: CHIPCE-8: CHIP-8 interpreter for the PCE]

I created an 8x7 pixel at 512x224. Then just write directly to the tile's vram. It was easy and sufficiently fast.

Hadn't thought about about those ways. I've read quite a bit about the VDC but don't have much practical experience. Perhaps I should fool with those ideas.

chipce-8 doesn't yet support SCHIP-8. Once I figure out a good way to do 128x64...

I believe chip8.com has a big collection. I will be adding all the documentation I've found and roms to github soon. Seems chip8.com is down right now...

https://drive.google.com/file/d/0BxNcO7ALeiejeFVuU2VJWkk2Mm8/view?usp=sharing

[Localizations, Games, Apps, Docs / Re: CHIPCE-8: CHIP-8 interpreter for the PCE]

User megatron-uk has a great start on a FAT driver. Semi functional if I recall correctly. It would be amazeballs if you could benefit from his work. I'd personally be fine with bram to sd.

Yup. I accidentally started an argument on the TEd forum about all that. Had just gotten my TE recently and asked for the firmware code to enhance the experience. In part to provide builtin bram transfer support. Got attacked for asking.

Anyway... I saw his work and forked his github repo. As last I checked write support was lacking. Just needs some love I'm sure. I did some quick research into working with SD cards a while back but got distracted with chipce8.

[Localizations, Games, Apps, Docs / Re: CHIPCE-8: CHIP-8 interpreter for the PCE]

The problem I'm seeing, is that some websites show the 64x32 res are square pixels (so a wide screen format) and some show this as rectangle pixels (0.5 pixel aspect ratio, full screen). Which one is correct?

"fairly square"

http://www.old-computers.com/museum/doc.asp?c=543

128 is the maximum vertical resolution. Since video data was passed to the 1861 with an interrupt routine this vertical resolution could be lowered by passing the same row several times. Usually this resulted in resolutions like 64 x 16 (popular on single board Elf computers with only 256 bytes (!) RAM since this uses only 128 bytes for video memory). Typically 64 x 32 (256 bytes video RAM) or 64 x 64 (512 bytes video RAM) were used.
Only 64 x 32 produces huge, but fairly square pixels. All other modes are somewhat limited in use by the odd aspect ratios of the pixels. That and the video memory of one whole kilobyte made the maximum resolution of 64 x 128 fairly useless. The pixels were extremely wide and flat.

[Localizations, Games, Apps, Docs / Re: CHIPCE-8: CHIP-8 interpreter for the PCE]

This is your new top priority, only with USB instead of Parallel.

Go ahead. Get started right away!!!

For real. This has been the unicorn I've been hunting for since the early 90's. You would be my hero, and that alone  would make the endeavor worth the effort, right?

Hah. I need to investigate Arduino more on how I could get the data to the PC. With my original I just had a simple cable connected to the joy port and parallel on the PC side with some simple software on each side (Linux for the PC). I actually was going to look into that next. I originally wanted to write something for the Turbo Everdrive but writing a FAT driver is more work than what I've in mind. Though raw writing to an SD card with the TE wouldn't be hard but not as nice.

Anyway... I'll look into it next.

[Localizations, Games, Apps, Docs / Re: CHIPCE-8: CHIP-8 interpreter for the PCE]

I really had no expectation that people would actually use this. CHIP-8 wasn't very good when it was new. Fun learning about it and the COSMAC systems though.

I was thinking of attempting a RCA Studio II emulator. I've had one for years and it's similar to the COSMAC systems. That too would be for the fun given it's awful as well. Years ago I made a simple PC Parallel to PCE BRAM transfer app and cable. Was considering doing that again but with an Arduino. The bigger project I have in mind is recreating Bloodlust Software's pong game Nogginknockers. I'm friends with the artist so I could probably get him to modify the graphics for me.

[Localizations, Games, Apps, Docs / Re: CHIPCE-8: CHIP-8 interpreter for the PCE]

Benefits of this are ?

The ability to play shitty CHIP-8 games on the PCE.

[Localizations, Games, Apps, Docs / CHIPCE-8: CHIP-8 interpreter for the PCE]

https://github.com/trapexit/chipce8

Something I was tinkering with a while back and finally got around to finishing. This version is currently done in HuC but I've got an assembly version in the works as well for comparison.

I also took the opportunity to document different CHIP-8 derivatives which were scattered among several sources for those interested.

Once I finish the assembly version I'll probably try to get SCHIP-8 fully implemented. Main issue is graphics.

[Localizations, Games, Apps, Docs / Re: HuZERO - a score attack PCE racing game FREE to download!]

And who will be the first to find the secrets?

[Console Repair/Mod Center / Re: Dead pc engine duo]

Noted. Thanks.

The damage to the main ICs seems like a plausible location for a problem. HuC6280's pin 16's trace to ground is damaged for example. All the silicon makes it rather difficult to get a good look at whats going on with the pins. However, without knowing when it stopped working it's difficult to know where to start.

I've already invested more time into this than it's probably worth. May end up being a parts board.

[Console Repair/Mod Center / Re: Dead pc engine duo]

And the IC520 on the Duo-R the same as Duo? Must it be removed or can a pin or two be lifted to accomplish the same?

I noticed C947 is not populated. Anyone know if that's expected?

[Console Repair/Mod Center / Re: Dead pc engine duo]

thesteve, thanks for this info. Are there any service guides for the Duo, Duo-R, Duo-RX floating around? Original or like the info in this thread? A step by step of what to check?

I just picked up a Duo-R that at the moment I don't have the history of unfortunately but it appears to be a botched video mod. The 6280 and 6260 were wired up and partially covered in silicon rubber. The wires were snipped so it's possible the mod was fine but the Duo-R stopped working so they just snipped the wires to get the components back.

Either way... the device turns on. Fuse and 7805's look fine. When on it displays a white or occasionally off white or blue or pinkish screen. Placing a HuCard in does nothing. I can post images of the 6260 or 6280 if interested but as far as I can tell there aren't any shorts or unconnected pins. I removed all the silicon rubber (that was a test in patience) and desoldered the wires left over and made sure to reflow the pins.

I don't have an oscilloscope or probes but with my multimeter it looks like the data pins are high as are the address pins.

Suggestions?

If I'm reading the thread correctly it was recommended to disconnect IC520?

[Localizations, Games, Apps, Docs / Re: CC65 for PCE/SGX]

Did you get anywhere with cc65?

[Buy/Sell/Trade / Re: New game raffle 8: Power Golf double header!]

Add me please. Thanks.

[Buy/Sell/Trade / Re: Military Madness Raffle.......]

Count me in.