Posts by robinsonb5

Quote from espskog

BUG FOUND: I see that when I enter workbench, the left + right fire buttons on the CDTV works fine as the left+right mousebuttons. But the arrow

keys do not move the mouse-pointer. When I press ARROW_UP it moves the pointer one pixel down. If I press ARROW_DOWN it moves the pointer one pixel to the right (yep: the switch is set to "mouse" on the CDTV remote).

That's not a bug - that's just how it works. The CDTV pad always emulates a joystick, not a mouse - the mouse/joy switch just selects which port the emulated joystick is plugged in to.

Quote

Also -- when I play Supercars (might be an issue with other games as well) I notice that there is a lag on the buttons. I press the fire button to accellerate, but it doesn't axx until about 0,5-1 second later. Also, if I try to steer with the arrow keys left/right it has the same kind of lag.

Could you see if this is also something which happens on the V1 ?

Sure, I'll try it. But is that Super Cars or Super Cars II? I can't seem to get Super Cars to run at all. If it is Super Cars 1, can you let me know which version you used? (Don't link to it here, though.)

Quote from Tobias

i will have to find a workbench adf and/or zeewolf 2

I'm at work now - but I'll find some suitable test ADFs later on - I have a couple of memory checkers and sysinfo, which should give some useful information.

Quote from Tobias

Unfortunately... this core behaves the same

how do i test if fast ram works (my amiga knowledge boils down to "insert disk to start turrican" =))

Enable fast RAM in the OSD menus, reset the Amiga with Ctrl-alt-alt, then boot a workbench disk and see what the free memory readout at the top of the screen says. Another good test is to enable Turbo Chip RAM and see if ZeeWolf 2 boots, and if so, how smoothly it runs.

If you get a chance and have an easy way to do it, could you give me an md5sum of the new OSD file, after copying it to the SD card?

Also, it might be worth trying the memory testing OSD file on the previous forum page - (though I think that will work just fine, since only instruction accesses for the OSD CPU use burst mode, not data accesses.)

OK - updated version here: http://retroramblings.net/snap…nimig_tc64v2_20190411.zip

One of my failed experiments with jab76 was reducing the drive strength on the SDRAM - and I realised I hadn't set it back again - so this version restores that setting, and also the timing constraints.

Quote from Tobias

but why does the older OSD work fine? because its smaller than 64k?

Good question. With the old OSD does Fast RAM work reliably or not?

(The OSD and Fast RAM both make use of burst reads, whereas chip RAM / slow expansion RAM doesn't.)

Quote from Tobias

mmmmh the core works for me, but with the included OSD i only get black screen. when i start the core without SD card inserted i can see it runs, then after inserting the sd card i see green LED blinking, monitor goes out of sync... with older OSD it works, but then the power button doesnt work on the remote. *shrug*

edit: tried with SDHC card instead of regular SD too... no dice. *sometimes* when i press the right button on chameleon to reset, the initial screen comes up with the OSD, which is then unuseable though. at this point inserting the sd card would do nothing. also tried on another v2 without rr-net, and also tried in standalone mode. same thing everywhere. also tried the OSD from minimig_tc64_20130608.zip - this already has this problem (?)

OK - I'd tweaked the SDRAM timings in between the last two released to try and address jab76's problem - I'll revert those changes and see if the result works better for you. Frustrating that my ChameleonV2 seems to be much more forgiving than other people's!

Here's a version that fixes the CDTV control pad issues. It's possible to open the OSD using the power button (new for V2 - I'll backport that to V1 at some point).

Things I learned:

• It's vital that the ir_data signal is double-synchronised, otherwise the state machine in the CDTV Controller module gets wedged.
• Somewhere along the line the order of the joystick direction signals in the CDTV ir module got reversed between the old version in the Minimig sources and the current version.
• If your project uses the CDTV ir module directly in its toplevel, it's a good idea to disable it in the IO module!

http://retroramblings.net/snap…nimig_tc64v2_20190411.zip

Thanks for the debugging help - I've just released an updated version of the core which is basically as per the most recent debugging core but with a tweak to the io module to prevent the C64 joystick interfering with keyboard scanning. This should prevent spurious presses of the start button when a joystick is in port 1.

http://retroramblings.net/?page_id=969

Quote from Tobias

hw test works, no glitches from C64 keyboard or joysticks

schematic is in the wiki: http://wiki.icomp.de/w/images/…ameleon_schematics_v2.pdf

Excellent, thanks. I think I might have cracked it - please test the attached when you have a moment.

(Comparing line-by-line the hwtest and PCE toplevel, I noticed that I wasn't writing default values to the clockport control lines, so a clockport device might be visible on the bus and interfere with the IO module. I think you have something attached to your clock port, and I don't - which is why the core was working for me and not for you.)

I still have to work around the interference between the C64's first joystick port and the keyboard, but that's relatively trivial.

Quote from Tobias

more weirdness...

first, i noticed when playing with the remote, the values in the second and third block are changing with some delay to the first block... sometimes

OK well the idea with the second and third block is that the second one will latch any recently seen zero bits, while the third block latches recently seen high bits - both are reset every second or so, on a fixed shedule for simplicity's sake, so it's normal for the delay to vary. The idea is just to make brief transients readable, since we don't have the luxury of signaltap here.

Quote

then... now that you asked for the fourth row, i noticed something else: when i run the core using chaco (power up, then use chaco to start the core slot) the third and fourth row are all zeros (and do not change ever). now, if i select the core in the chameleon menu, the third and fourth row will contain somehwhat random values (that dont change either) - but ONLY if there is a sd card inserted when the core starts. when i remove the sd card before, the values will also be all zeros.

That's *very* weird. Is there a schematic available for the V2 hardware?

OK let's go right back to basics here. Here's a build of Peter's hardware test core, which he updated recently to fix the transients I was seeing on my setup. So this is the same version of the IO module, built with the same version of Quartus as the PCEngine core. Could you just double check that this works correctly on your machine, please?

Quote from Tobias

now there are three blocks like above... all rock stable, no reaction to joystick, c64- or ps/2 keyboard whatsoever. cdtv remote seems to work ok.

OK - and what's the first digit on the fourth row, please? It should be a 3?

Quote from Tobias

the first row is totally stable, and nothing changes when i press keys, wiggle joysticks etc

in the second row the leftmost two 3F react to CDTV remote, this seems stable to me too

in the second row the rightmost two 00 are mostly zero, but occasionally show different numbers (cant tell which, its too fast)

bottom row is all 0s most of the time, with seldom glitches to other numbers (again, cant tell)

OK thanks, that proves that the problem's with the joy and key outputs of the io module, and not being masked by something else. Here's another build with the IO module running on a clock closer to 100Mhz, and which latches the transients briefly so we can get a closer look at them. (Assuming they haven't now gone away!)

Hi,

Here's another build - this one won't fix anything, but I've added a new page to the on-screen menu - Debug - which shows in realtime the status of the docking station ports, cdtv controller, some of the keyboard matrix and the c64 joysticks.

When you have time could you let me know whether the numbers shown here are stable or fluctuating, and whether any of them respond to the joystick, please?

Quote from jab76

robinsonb5: I've flashed both cores to the Chameleon and did some testing with the memcheck file. The first core resulted in the same blue screen as before. With the second core all went black. I will try this again, but I haven't got the time right now.

With the large osd file both resulted in the red screen and with the small osd file fast ram wasn't recognized.

OK, well thanks for taking the time to test. I'm running out of ideas now - I'll see if I can come up with some kind of test for SDRAM bursts, but it'll be some days before I can do that.

Quote from Tobias

all kinds of C64s, breadbin, c64c, pal, ntsc, MK1, MK2 etc

unfortunately this core seems to behave the same (only tested on my main c64, which is a PAL C64C)

Sounds like quite a collection!

Thanks for testing - I'll see if I can devise another test to narrow the problem down. (Too bad you don't have a USB-Blaster - this would be much easier to trace using SignalTap.)

OK thanks for that. Are any of the 6 C64Cs or are they all breadbins?

Here's another core, with the IO stuff migrated to the 84MHz clock - please let me know if this behaves any differently. (It won't fix things completely because there's still a small window where the joystick interferes with keyboard scanning. The symptom will be releasing the joystick causing a phantom triggering of the start button. I may end up pulling the CDTV controller module into the toplevel and not allowing it to be merged with the keyboard, in order to avoid this issue. )

Also, another thought that struck me today: I remember another project where I had SDRAM issues which were cured by reducing the drive strength of the SDRAM signals. Here's a build with all signals reduced to 4ma drive strength (the default's 8). Again, will be interesting to find out if it makes any difference.

Quote from Tobias

it'd be great if you'd have a look... i will play around with it a bit perhaps, but it'd be pure luck if i find a solution for this

Sure, no problem. In the meantime I saw in another thread that you have several C64s to hand - if you get a chance, could you let me know whether the issue's the same on all of them, or if it varies at all between machines?

Quote from Tobias

played around some more.... both cores work in standalone mode. in cartridge mode the second one registers "enter" on the ps/2 keyboard to start a game, but then the joystick apparently is being constantly "pressed" up/right/fire (perhaps polarity of signals reversed?)

the source is on your github, so i can stare at it a bit, i guess?

OK. I must confess I've only tested in Cartridge mode (on my C64C) but it works there, so it's not a simple case of polarity reversal.

The only thing I can think of that might cause problems is the IO module being clocked at 126MHz (the HWTest runs it at 100MHz) - there's an 84MHz clock available, too, so it might be happier running on that, but the ena_1mhz signal will need to be moved to that clock, too - and its counter adjusted accordingly.

If you want to play with it from GitHub, the Chameleon V2 target is on the "split rom" branch. Otherwise I'll take another look late tonight.

Quote from jab76

robinsonb5 I've tried with the attatched OSD file. There are no addresses scrolling by. Just a blue screen.

And with the memcheck core, the stripe stays green.

OK - well that reinforces the idea that the problem is with burst transfers. Here's yet another build (which, again, works fine on my TC64V2) - this time I've phase shifted the SDRAM clock a bit further, and also tightened the timing constraints. Could you let me know, please, if you see any change in behaviour with this version?