Jump to content

Yazwho

Members
  • Posts

    126
  • Joined

  • Last visited

  • Days Won

    2

Yazwho last won the day on April 11

Yazwho had the most liked content!

Recent Profile Visitors

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

Yazwho's Achievements

Contributor

Contributor (5/14)

Very Popular Rare One Year In Reacting Well Conversation Starter Dedicated

Recent Badges

107

Reputation

2

Community Answers

  1. It is, I asked the same thing a while back as it caught me out as well. The DATA registers are set when the address changes, not on the actual read. When you read, the address changes and thus the register updates. Before the next read if the data at the register changes the register will not reflect the new value. I worked around it like this.
  2. Things have changed since then. VIA is now at $9f00, and the banking is at $00 / $01.
  3. As I said, if you want to be involved, write up the test for where you think there might be a gap, and pop onto Discord. Or post it in the downloads section, apps that can be used in testing (especially edge cases) would always be helpful. However if you're suggesting writing a network debugging app for those who are involved in the development, then no need, as if it was needed it would be done already. There doesn't appear to be any problems with that workflow.
  4. if you want to write testing code, that could be helpful. Create the .prgs and pop into Discord and I'm sure someone with hardware could run it and take a picture.
  5. I think the Mega 65 team did this to help develop while they had very few boards. IIRC their emulators at the time weren't that complete, which is why it was needed. The current emulators do a very good job. There are some slight differences, especially around how each line is rendered, but on the whole for most cases it should be good enough. What edge cases are you looking to explore?
  6. If it's just a vram issue, then ZeroByte suggested a way around it. At the end of the day there are lots of ways to mitigate the issue, but I dont think changing the machine is one of them. This is meant to be a limited machine afterall. There are plenty of people on Discord who can offer suggestions, workarounds, or can just talk about things in a more conversational way than can be done here. Maybe thats worth a go?
  7. You mean coordinating the moving of a lot of sprites on the screen on every frame -- say 1160 of them -- like this?
  8. 64 x 64 is very useful though. As would be 128 x 128 and 256 x 256 if there were 1bpp and 2bpp modes available. Vera only has one resolution, 640x480, we use scaling to create 320x240 or indeed any other 'resolution' lower than 640x480.
  9. Someone with more knowledge can correct me: The sizes are so vera can pull data quickly, as it can mask or shift the address to look up the sprite data. At 48bits the maths become more complicated as it would have to calculate the offset first which would reduce the number of sprites per line.
  10. If you don't like cracktros, you can of course buy the game.
  11. Looks like the code above had a little mistake, the Clock was a 32bit integer, which wasn't big enough! The actual number of ticks is $18CE3A5CB, or ~1400Mhz. Almost there, although MASM is a right pain the arse. A project for the future is a general templating took like the 65c02 Bitmagic one!
  12. If only I knew C. I just something that's never really interested me, which was reinforced trying to get the C test harness working for this!
  13. I changed all `pushf` and `popf` and reengineer it using `lahf` and `sahf` which has had a massive effect on performance. I read pushing the flags onto the stack was expensive but I didn't figure it would be this profound! It now runs the same code in 6s. So thats 2,363,729,355 / 6 = 393,954,892 ticks per second, or ~394Mhz. Thats with a test that has plenty of low cycle opcodes that are the more expensive to emulate than the 4 or 5 cycle ones. Good start to the weekend!
  14. First noddy results are in. The code below results (I think) in 2,363,729,355 clock cycles of the 65c02 to complete (ie get to the last stp), on my PC (7700k - 4.2GHz) it takes ~19.5s, this includes a small overhead for compilation and the other bits that VS and .net have for running the emulator. Discounting that, its ~121,216,890 cycles per second. So ~121Mhz? I have no idea if thats good or not? Especially with the overhead that has to be added like interrupt handling and post\pre write address handlers. (Bank switching, etc) lda #$50 sta $02 sta $03 ldy #$ff .mainloop: ldx #$ff .loop: dex bne loop dey bne mainloop lda $02 tax dex txa sta $02 bne mainloop lda $03 tax dex txa sta $03 bne mainloop stp
×
×
  • Create New...

Important Information

Please review our Terms of Use