Gau_Veldt

Members
  • Content Count

    26
  • Joined

  • Last visited

About Gau_Veldt

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Interests
    Computers, AI, Games, hardware and software Coding, FPGA, retro computing, consoles

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. From the C64 kernal disassembly ( https://github.com/mist64/c64rom/blob/master/c64rom_en.txt ): .,FCE7 20 02 FD JSR $FD02 scan for autostart ROM at $8000 .,FCEA D0 03 BNE $FCEF if not there continue startup .,FCEC 6C 00 80 JMP ($8000) else call ROM start code .,FD02 A2 05 LDX #$05 five characters to test .,FD04 BD 0F FD LDA $FD0F,X get test character .,FD07 DD 03 80 CMP $8003,X compare wiith byte in ROM space .,FD0A D0 03 BNE $FD0F exit if no match .,FD0C CA DEX decrement index .,FD0D D0 F5 BNE $FD04 loop if not all
  2. As an aside when I went looking for C64 FPGA snippets or significant parts (VIC, SID, etc) of it I hit a lot of nasty paywalls (and/or licensewalls) hence why I did it myself AND made the sources freely available on GitHub. Edit: Oh yeah, and lots of abandoned stuff or out of date (and/or whose latest version is behind a paywall/licensewall).
  3. This is where it helps to have the disassembly of the KERNAL ROMs. Anyways: from c64-wiki.com: the cartridge ROM will use the GAME or EXROM lines (by pulling low) and the ROM will appear in the C64 address space from $8000. The start address of code to boot in the cartridge ROM gets stored at $8000,1 and the address of code to run on NMI has its address placed at $8002,3. Finally the CBM80 magic signature must appear at $8004,8 "CBM80" in PETSCII. I should point also that the ROM address lines will be relative to the ROM offset, not the C64's bus address (so address at the cartridge ROM's
  4. I actually did this project to learn FPGA development. and I have learned a few things that I'll apply to future projects but here's the highlights: 1. Bidirectional buses don't work at all on FPGAs. Buffers are very limited resources on most FPGA topologies. This means split the bus and have it separate for input versus output (eg: have dataOut 7:0 and dataIn 7:0 buses for data). This one's a real pain because pretty much all old school computer logic uses some form of bidirectional bus. You can interface an external (external here means external hardware only if it's buried in a s
  5. PSS: If by software simulator you mean logic simulation for the design sources then that's already available in Vivado at deisgn-level, synth-level or implementation-level simulation contexts. It's just they are really really slow, especially the synth and implementation sims. Expect a good few hours just for the second-or-two RAM test the C64 Kernal starts with (that you have to wade through because none of the interesting stuff where you see bugs such as interrupts going wrong in CPU sources will happen until after that test runs and the Kernal turns on interrupts). Just one VIC video fra
  6. PS: I used that python script to generate compile-in ROM VHDL library includes out of the binary images for the Chargen, Kernal and BASIC ROMs. I don't put the ROM function sources into the github repo for obvious reasons (cough DMCA takedowns cough) but the Python program to convert a ROM binary dump you already have into a VHDL library source is there. It would just need to be copied to another pyhton and tweaked slightly to make cartridge ROM sourcefiles.
  7. Just a quick rabble on those three points: 1. Software emulators for C64 are already quite plentiful VICE being among the better ones. 2. I've got majority of the design complete for a running C64. There are some missing bits I need to still add (the SID volume envelopes, ring and sync mod, VIC sprites and bitmap modes). I ran into some issues with emulating IEC so there's still no disk/floppy image support. EOI and ATN overrides were causing me grief. I took a pause at this point and decided it might be time to get a Raspberry Pi going with a breadboard that speaks SPI over one
  8. Loberman basically already indicated what you'd need in HDL. I'll just add most boards have a downloadable constraint file (at least this was the case for the Zybo). Copy it into your project's (right clicking on the constraints in the sources pane followed by add new constraint files ensuring to check the "Copy files to project" option) constraints folder then open the constraints file (I'm using Vivado btw) and uncomment the lines for the desired pins (in this case one of the PMOD ports). Be sure to check the hardware manuals that the PMOD port chosen is appropriate
  9. What's going to happen here is that the synthesizer is going to generate your design and optimize out any signal assignments that cannot be reached (or that are reached but overridden by a later assignment) on a particular path through the process. All possible paths that modify a particular signal are then strung into a MUX determining that signal's value. There will be one such MUX for each different signal the process assigns to (and in this case each MUX will also be coupled to a register clocked by someClock). It's not like a programming language where a series of assignments will be r
  10. Just to put in perspective 2^256 is a base ten number with around 77 zeros. Let's divide this by 1000 THz for an imaginary design running at 1 PHz (petahertz which has 15 zeros) that can do the entire elliptic curve, ripemd160 and comparison to your target hash in one clock cycle (this pure fantasy is to simplify things by starting from a whopper hyperbole of a best possible design that cannot be achieved in practice). Now we're at a number with around 62 zeros ~= 10^62 or so seconds. 60 seconds is one minute, 3600 seconds is an hour, 86400 a day, 3.162*10^7 is a year (around 31.6 milli
  11. I've driven PMOD lines directly from HDL as part of a PWM driver to vary the brightness of LEDs when connected (via resistors) to the PMOD line jumpered onto a breadboard from one female end of a 12-to-2x6 PMOD splitter cable (the other end I reserved for plugging in a keyboard via a PMOD PS/2 adapter). It works fine to uncomment the appropriate PMOD port lines in the XDC file (and add those pin names into the entity declaration, as output in my case). In VHDL something like your problem I'd achieve by first using the clock wizard to make the initial 10 MHz clock, uncomment the de
  12. Short answer: If there is a Scratch (https://scratch.mit.edu) server that will interact between the Discovery 2 and Scratch, GET IT! It means you could plug any sort of hardware (like a temperature sensor or an IR sensor) that generates readings into the Discovery and have it send that information to the Scratch project meaning a character would be able react (say having a sprite's face go red with increasing temperature) to a signal or waveform sensed at the Discovery. This gets even more interactive if the kids make their own hardware that sends data into the Discovery (think
  13. Future projects may include clones of other machines or consoles (Apple II, the infamous NES, TRS-80, Amiga there are lots to choose from) and some other projects such as hardware LSTM (long short term memory, used for AI). The challenge for some will be memory (meaning I'll have to make a design that speaks AXI and uses the PS's DDR memory) since things like space for the NES game ROM memory or Amiga 500/1000 memory (including OS ROMs). The really big ones like loading a game ROM also aren't suitable for my python ROM-to-hdl script nor Vivado's RAM initialization file workflows.
  14. I thought Xilinx used bitstream encryption "for security" and to prevent leaking IP's to intruders (read: open source reversing engineers).