Jump to content

SvOlli

Members
  • Content Count

    297
  • Joined

Community Reputation

220 Excellent

About SvOlli

  • Rank
    Moonsweeper

Profile Information

  • Gender
    Male
  • Location
    Hannover, Germany

Recent Profile Visitors

8,834 profile views
  1. I'd rather support one step at a time: first build a good baseboard, then see what it can be plugged into. And with the baseboard utilizing a 6502, just using it as a 6507 replacement would be plain simple: connect IRQ and NMI to +5V, and keep A15, A14 and A13 unconnected. A bit more interesting would be adding a GAL chip creating the chip select signals in a way that RAM could be placed at $1000-$EFFF. Or even $1000-$FFFF that can be loaded (with an UART for example) by a small bootrom that then turns itself off. At least that was the kind of expansion that I looked into with my try to build a PCB. But that's something open to discussion once we've gathered enough substance. The other idea I had was to utilize a 6502 B which is capable of running at 3MHz. This could be overclocked to 3.57 MHz then running at the same frequency as the TIA. But this will almost certainly not work, because there's a feedback from the CPU frequency back into the TIA. Also the 6502 B is way much harder to source than the 6507. Rereading what I've just written, I noted that if done right, the "RAM expansion" can be done _outside_ of the baseboard, if the baseboard has slightly more output that just the cartridge port pins. If we use just standard 2.54mm connectors, the other side could be either a cartridge slot, or that vaporware RAM board, if not only D0-D7 and A0-A12 get put on this connector, but (at least) A13-A15 and R/W as well. That way we'd still have the "pure-with-6502" option, as well as the RAM board one, based on the same baseboard. I am absolutely positive that a PCB with two CPU sockets (one for 6507, the other for 6502) would be possible, if only one of those two has a chip put in it. A bit more tricky will be trying to allow both PAL and NTSC TIA fitting. The solution I came up with so far would need at least some jumpers. Looking forward for this project to throw my 2c and work in it.
  2. Since it's been quite some time, I can't remember for sure. But I think I found some German reseller on eBay who charged for a single one about as much as your find wants to have for a pack of 10.
  3. Yes, now it's tested, and I can tell which bytes differ between download and cartridge.
  4. Fine, now I can dump my effort on doing a 2600 board. The CPU board idea is quite interesting, since I wanted to do a version that's as compact as possible. What also could be nice would be an option to use a 6502 instead of the 6507, since those are easier to source.
  5. It is yet untested, as the package arrived, when I was out for groceries. It I had known, I would have skipped the groceries. Test will be conducted soon.
  6. Here's some code I use for bankswitching. It's a modified version of the code used in Bang! There it's done with code generation, so this code differs. The cool part is that the banks are encoded in the upper 3 bits of the address when jumping to a routine. Note the comments when trying to use it, some lines need to be removed according to the bankswitching used. There is a frontend used by macros that enable the jumping across banks, as well as for RTS. These need A and X for calculating the bank and the jump. The backend expects the code for calculating the jump at the same address in each bank. I suggest ti put it directly before the bankswitching hotspots. Also note that the RTS will trigger a read on the following byte, so putting this before the hotspots is a very bad idea. ; macros for using ; all bankjumps overwrite A and X registers .macro bankjsr _addr ldx #<(_addr-1) lda #>(_addr-1) jsr bankjmpcode .endmacro .macro bankjmp _addr ldx #<(_addr-1) lda #>(_addr-1) jmp bankjmpcode .endmacro .macro bankrts jmp bankrtscode .endmacro ; this code needs to be replicated to all banks ; to the exact same address bankjmpcode: pha txa pha bankrtscode: tsx lda $02,x asl rol ; remove when F8 rol ; remove when F8 or F6 rol and #%00000111 ; use this for F4 and #%00000011 ; use this for F6 and #%00000001 ; use this for F8 tax lda $fff4,x ; use this for F4 lda $fff6,x ; use this for F6 lda $fff8,x ; use this for F8 rts bankreset: lda $fff4 + (reset >> 13) ; use this for F4 lda $fff6 + (reset >> 14) ; use this for F6 lda $fff8 + (reset >> 15) ; use this for F8 jmp reset ; this is padding for the bankswitch bytes .byte $f4,$f5,$f6,$f7,$f8,$f9,$fa,$fb ; use this for F4 .byte $f6,$f7,$f8,$f9,$ff,$ff ; use this for F6 .byte $f8,$f9,$ff,$ff ; use this for F8 ; reset vector .word bankreset ; irq vector .word bankreset For me this was some kind of the golden solution to the "bankswitch-problem". Still you need to keep code and data in the same bank, but for my demo this never was a problem... Also note, as these code fragments are taken out of the demo and modified for this discussion, so there might be bugs in there. If so, let me know, and I'll try to fix this. The demo was also coded using ca65 so the syntax for other assemblers might differ.
  7. If it's just about an index for an animation, I would do it the other way round: counting down, so you can spare the compare: ldx counter dex bpl @noreset ldx #$02 @noreset: stx counter All you need is to reverse the order of the animation frames. But Andrew's a bit faster... of course. But mine's one byte shorter.
  8. Is this code tested? I'm wondering how this possibly could work since it's not handling chip select, so it's corrupting the data bus, if anything else, like RAM, is selected.
  9. So what? Defeating most (if not all) types of encryption is easy. All you have to do is to implement a trigger for bankswitching, which is not too complicated after dumping and disassembling the first bank. Only way I know to defeat this is using a Harmony/Melody board with code running in the ARM microcontroller.
  10. Found it! It's at 17:44 in this video: But I recommend watching the whole video.
  11. I picked the wrong video, without verifying it. I remember viewing a talk by David Crane about Grand Prix, where he stated that they were lucky that the bug was never fixed, because they could use it to hide the "wrapping around" of sprites. I looked through my archives, but can't seem to find it... strange. Maybe someone else can step in here. Or I can dig it up later.
  12. As Master Phruby already pointed out, it is part of the design of the TIA. Consider it a bug in the chip that was turned into a feature for some use cases, like David Crane described it in his talk about Grand Prix:
  13. Not a killer hack, but still something I found useful. For easy notation: "A" means accumulator, "R" is a value stored in RAM. So, doing "A minus R" is easy SEC SBC R I was faced with the problem of doing "R minus A", remembering of something I learned at school called "2s complement", I came up with this: EOR #$FF SEC ADC R So, what I did there was "minus A plus R". And it worked like a charm with a "cost" of two bytes and two cycles. And also: That's a very nice idea. But "spending" 1/16 of a bank seems to be a bit expensive. But coding for coding for other 6502 based platforms (C128/C64 right now), I will definitely use this, as the table could be also created with a simple loop in RAM. (That would be a fun thing in SuperCharger.) Thanks!
  14. When I did the research for my talk a couple of years ago, I found an advertisement for development system that was an expansion cart for the Apple II that had a daughterboard that would go into the 2600. But doing a quick search now, I couldn't find any of those stuff any more. Edit: d'oh! I should click on the links of the other posts before posting myself. The Frob is most probably the dev-system I've seen a couple of years ago, though I only found an advertisement back then.
  15. I've gone to using TIMINT very early in my efforts to get code running. Since it's long ago and I'm using my old code ever since unchanged, there's how I remember it: - just write to TIMxTI instead of TIMxT (it might be that the ...TI is not defined in vcs.h, then go for (...T | 0x8) - instead of waiting for the timer to zero out, I'm waiting using a loop like this: "@loop: bit TIMINT : bpl @loop" And that was all. If you like, you can take a look at the code of all of my releases. They are available at: https://xayax.net/ . A rather simple demo is this: http://xayax.net/2k_is_no_limit/ . I've got three functions (in main.s) there "waitvblank", "waitscreen" are called using "jsr" and just wait until the beam has passed these areas. "waitoverscan" is called using jump and does more than just waiting, as it contains logic to decide on what to run in the next frame and generates the sync signal.
×
×
  • Create New...