Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.
Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.
any way we can support you robinsonb5? I'll happily send a pint your way, Pengo is such a fantastic gem.
Thanks for the thought - I'll look into setting up a virtual tip jar at some point.
In the meantime, Pacman is 95% working, and Pengo nearly works, so I should be able to release the arcade cores before too much longer.
It will be a long time before we see on v2 arcade already available on v1 (Moon Patrol, Pengo etc) and other arcades like Ghosts and Goblins.?
Many thanks
To be clear, this is just a list of cores that could potentially be ported, with the rather optimisitic intention of tracking who's working on what, to avoid duplicating effort. It's not a promise that any of them will be ported!
Having said that, I do plan to port the PACE cores to the new hardware in the near future.
As said, we are very reluctant to removing features - which would be needed to do this. I'd favour second button = potx myself, i don't see it happening however
Why not add a menu option somewhere to switch modes - or maybe map a little-used key on the remote to mode switching?
It's a line output, not a headphone jack - so you should use an external amplifier and connect headphones to that instead.
Just did a quick test... seems to work. I got some weird problems with one SD card, it showed a bunch of empty directory entries and i couldnt select the ROMs i copied to it. with another fresh card it worked. would be great to have a readme in the zip that tells me where the buttons are mapped to on the keyboard =)
Thanks - I've given the release a page on my blog, here - http://retroramblings.net/?p=1246
Good point about the controls - I've listed them on the release page, but I'll include a readme next time I make a release.
Not sure what's causing the SD card issues, but clearly I need to revisit the FAT code at some point.
(Also, the ported cores thread gives the impression that I'm the author of several cores - I can't claim that much credit, having mostly just ported them and made some improvements here and there.)
Here's an initial port of the Sega Megadrive / Gensis core to V2 hardware. This is merely a port of the V1 core, and doesn't incorporate any of the recent upstream improvements.
retroramblings.net/snapshots/fpgagen_chameleonv2_20190505.zip
Please test and let me know if you encounter any problems. It should support CDTV pads, C64 joystick (though only one button) and PS/2 keyboard mapping for both players.
i cant really read anything, i think it prints like 2 or 3 lines of text after the "initializing sd card" and then the screen goes black
OK, well that either means its loading, checking the checksums and believes everything's fine, and then allowing the minimig to boot, or failing to load the checksum file. I'm going to have to give some more thought on the best way to debug this by remote control!
wow... thats surprising. it could point to the lowlevel spi code being broken, but i cant imagine in what way to result in this behaviour. *shrug*
Yeah, very odd isn't it? I'm inclined to think that since jab76's problem went away it was indeed an SDRAM problem, and the problem you're seeing has a different cause.
Here's another build - the only change is that now the OSD bootloader will attempt to open a file called "checksum.bin" and if successful, compare the contents against 32-bit checksums of successive 512 byte blocks of the OSD firmware, before launching it. Any mismatches will be printed to the screen, and cancel the boot. The OSD itself is the same as the previous build.
Could you try this, please, and let me know if it prints anythig to the screen, or whether it boots.
If it does find any mismatches, does it fail consistently, or do the numbers change each attempt?
you've got PM
Thanks for the disk image - annoyingly, having copied it to a suitable SD card it works just fine. So I'll do a build that checksums the menu code after loading it and compares against a preset list. I'd like to know whether it's always the same part getting corrupted.
robinsonb5 I've tried this core and OSD file and I can confirm that now Fast RAM works for me. Also, Zeewolf 2 plays a lot faster.
With this OSD file though, if I select scanlines, they do not appear to be working. I think they worked in one of the previous combinations, but I'm not sure.
Glad to hear this core's working better for you.
Scanlines only work if the scandoubler's active, and since you were previously only able to use an older OSD you had no control over that. Try holding down F1, F2, F3 or F4 on the PS/2 keyboard and pressing the reset button - that should force NTSC scandoubled, PAL scandoubled, regular NTSC (480i / 240p) and regular PAL (576i / 288p), respectively.
Hi!
I think there's a typo in the list, AFAIK BBC Micro was never ported to TC64v1... Or am I wrong?
I think you're right - it's my memory playing tricks on me. I think I was thinking of Mike Stirling's DE1 core.
Here's a list of existing FPGA cores of which I'm currently aware, which could potentially be ported to the Chameleon64 hardware. Most of these exist for competing hardware - some will be easy to port, some will be very difficult. The discussion about cores and porting was in danger of getting lost in the chatter in the "Ported to V2" thread, so I thought a list such as this would be helpful.
In the interests of avoiding duplicated effort, if anyone else is working on a core, especially porting to V2 hardware, it would be helpful to know, so that no-one else picks up the project. For this reason I've put my own initials by the projects either done by me, or on my "To Do" list.
If anyone knows of a project that should be added, or if anyone else is working on porting any of these please post below and I'll update the table.
| Home Computers | Ported to V1 | Ported to V2 | Effort required to port | Adopted by | Notes |
| Acorn Archimedes | moderate | Will require an OSD / disk co-processor in the core, and an associated extra port into the SDRAM controller. | |||
| Amiga (ECS) | yes | yes | AMR | ||
| Amiga (AGA) | high | Will require an OSD / disk co-pro + SDRAM port, FPGA nearly full | |||
| Amstrad CPC | |||||
| Apple II+ | |||||
| Apple Macintosh | |||||
| Atari ST – MIST | high | Will require an OSD / disk co-pro + SDRAM port, FPGA nearly full | |||
| Atari 800 | yes | yes |
MW | ||
| BBC Micro | |||||
| Commodore 16 | |||||
| Commodore 64 | Built-in | Built-in | PW | ||
| Commodore PET | |||||
| Commodore VIC-20 | yes | yes | PW | ||
| Mattel Aquarius | |||||
| Next186 IBM PC | yes |
very high | Last time I looked, not easy to build on Altera FPGAs | ||
| OneChipMSX | yes | yes | moderate | AMR | There's a newer version upstream that will require more effort to port. |
| Sam Coupe | |||||
| Sinclair QL | |||||
| TRS-80 Model I | |||||
| ZX Spectrum | yes | ||||
| ZX80/ZX81 | |||||
| Consoles | |||||
| Atari 2600 | yes | yes | PW | ||
| Atari 5200 | |||||
| Bally Astrocade | |||||
| Colecovision | |||||
| Nintendo Game boy | |||||
| NES | |||||
| NEC PC Engine | yes | yes | moderate | AMR | There's now a newer version that will require some effort to port. |
| Sega Master System | |||||
| Sega Genesis / Megadrive | yes | Low / moderate | AMR | There's a newer version that will require more effort to port. | |
| Arcade | |||||
| Frogger | |||||
| Galaga | |||||
| Galaxian | |||||
| Moon Patrol | yes | yes |
AMR | ||
| Pacman | yes | yes |
AMR | ||
| Pengo | yes | yes |
AMR | ||
| Space Invaders | |||||
| Ghosts and Goblins | high | Will require an OSD / disk co-processor – published source difficult to build | |||
| 1942 | high | Will require an OSD / disk co-processor – published source difficult to build | |||
| 1943 | high | Will require an OSD / disk co-processor – published source difficult to build |
good news... it still works with the "clean" sd-card.... bad news is, it still crashes with the other (which is likely fragmented)
OK great - is there any chance you could send me an image of a card on which it fails to load?
OK here's a new core and a new OSD file to go with it. The core contains new boot code written in C, which should deal better with following cluster chains than the old ASM code - or at least be easier to debug if it's still not working correctly. There is also a new OSD file - the only difference between this and the previous version is that the location of the stack has changed.
(The old OSD file will still work, but its stack overwrites the boot code (which is quite a bit larger than it used to be), so when the Chameleon is reset it will lock up and fail to reboot.)
edit: holy maccaroni! thats it... formatted sd card, copied OSD on it as first file, then kick.rom, then some adfs.... and it works. so indeed, this very much points at a bug in the initial loader
That's great news - thanks for testing. A long time ago I experimented with replacing the OSD CPU with a ZPU instead of the TG68 (since the latter is quite large), and in the process rewrote the boot loader in C. I'll build that version for 68K and see what happens...
no, newer OSD doesnt work at all, on any of the v2 cores
OK. Well now I know that Fast RAM isn't supposed to be working with the older OSD, I no longer think it's an SDRAM problem. I suspect now that the very minimal filesystem code in the OSD CPU's boot ROM isn't properly following cluster chains - so your earlier comment about the older OSD being less than 64K could well be the reason it works and the newer one doesn't. Just out of interest, how do you format your SD cards?
Display Morethe core works, but still no change regarding behaviour with fastram....
correct, one named "memory at 0x00c00000", the other "chip memory at 0x00000000". no fast ram
speedtest in sysinfo shows 0,6Mips
btw, just to say it uncase i didnt - i always used my old sd card before, containing this older OSD. it probably never worked with the newer one.
I've just put the older OSD file on an SD card and tried it - I didn't realise it was quite that old! The way Fast RAM is configured has changed since then, so you won't be able to configure fast RAM with the old OSD.
Does the new OSD work on the newest core?
Here's an initial port of the OneChipMSX core to the Chameleon V2 hardware:
http://retroramblings.net/?page_id=935
Please note, this is just a port, and doesn't include the upstream changes from the last few years.
What should i look for?
Could you enable Fast RAM in the OSD, Reset the Amiga then run SysInfo, and see how many memory regions show up on the Memory page. With everything maxed out there should be four - one starting at 0x40000000, one starting at 0x00200000, one starting at 0x00c00000 and one starting at 0x00000000
I suspect that you're only going to see the latter two.
If you run the speed test you should see a speed of about 9 MIPS. If Fast RAM isn't enabled it will be significantly less.
If the Fast RAM is showing up, then could you run the two memory testers, please, and let me know whether they throw any errors?
Edit: and here's another core to test, please. (No actual changes except to phase shift and build settings, unpicking some more changes from troubleshooting jab76's issue, in the hope that it will behave on your Chameleon once again.)
Workbench says 314,something "other mem" regardless how much fastmem i enable in OSD. zeewolf 2 boots and runs, but i have now idea if the speed is what you'd expect =)
Here are a couple of diagnostic tools: http://retroramblings.net/downloads/diagnostic/
Could you try them with and without Fast RAM enabled? (You'll need to reset with ctrl-alt-alt for changes to take effect.)
