Jump to content

TomSon

New Members
  • Content Count

    46
  • Joined

  • Last visited

Community Reputation

98 Excellent

1 Follower

About TomSon

  • Rank
    Space Invader

Profile Information

  • Gender
    Male
  • Location
    Cologne, Germany

Recent Profile Visitors

4,722 profile views
  1. TomSon

    VecFever

    I've given the DS2431 code to Malban for his Release/Quappe - so those tested DS2431 source files are in the Release source code. The code can also be developed/tested via VIDE already. If that's not enough PM me - I myself use a custom VecFever cart. where I can download and test new 1-wire code+hw immediately. Most of my games are 64k but at the same time use a 1-wire setup for storing/loading options/scores - that's possible if the data accesses to the 2nd bank are rare and esp. a lot faster than access time of the 1-wire chip. VecFever detection is simple - there's a communication structure that flags to the VecFever what type of features one wants - e.g. 0-7fff read/writeable, or load/store capability, or LEDs etc. - and the VecFever, if present, sets an 'I exist' flag in there. I could store inside the ARM chip itself also - not on the drive - and did just that on related projects of mine but for the VecFever it doesn't make sense. However, I have implemented an abstraction layer using overprovisioning and delayed erasure of blocks so storing on the drive is near-instant and safe long-term since I only erase a block when I absolutely have to and shuffle those blocks around. It's a .lot. faster than storing on a DS2431, for example.
  2. TomSon

    2048 '4K' Version

    Well, I respectfully disagree - I've played Threes for a while again and do prefer 2048. 2048 feels more like a Rubiks Cube with some randomness thrown in. There are ways of beating it one can find/puzzle out. Plus the power-of-2 values are just mesmerizing to a mathematical person and/or 8-bit programmer. It does mean that there is an uneven skill progression in 2048 and you need a while to get to your current level of skill - which I myself don't find annoying. With just a small change to the rules this can be improved upon, which doesn't affect the more complex parts later that much, but I still feel it's unnecessary. I did however add this second ruleset to a 'deluxe' version that will see the light of day eventually. Probably. The rule change is simple: I allow more than two of the same tile values (pre move) to be combined for an exp(2) higher value, so 2-2-2 = 8, or 4-4-4-4 = 32.
  3. TomSon

    2048 '4K' Version

    You are on the right track - there's a strategy that allows you to easily get to 1024 almost without thinking that I use myself. Only afterwards does this strategy break down and I need to get more creative to reach 2048. So far I haven't managed 4096 yet but I was close at one time, already had the 2048, 1024 and one 512
  4. TomSon

    VecFever

    how time flies.. so here's the current state of things: I have build and tested most of the VecFevers I plan to offer soon now but still don't have the time in the moment to actually organize this. Those were build whenever I could spare some time during the summer, including 50 in a black case with LEDs:
  5. TomSon

    2048 '4K' Version

    Hi, I’ve written a version of 2048 - a small puzzle game, originally by G. Cirulli - and kept it within the 4K rom limit of the smallest, original GCE cartridges without having to compromise anywhere. https://en.wikipedia.org/wiki/2048_(video_game) It has an attract mode, sounds and keeps the current high score in the Vectrex high score string just like the old games (so it is temporary and you see it by pressing reset). Obviously you can play this on a multicart where you can add games but since it is so small you can also quite easily build your own cartridge by converting an old one using a 2732 eprom and an original Vectrex 4K pcb. I myself used a dead Berzerk cart. whose pcb/shell was lying around here for a few years. In case you’ve never considered this: the Vectrex masked roms have /OE and A11 switched compared to a 2732 so you have to reroute those lines. It’s quite easy since all you have to do is cut the two lines wiggling under the eprom on the component side and reconnect. So I’ve just cut at the red lines (didn’t have to for /OE since that trace was already missing), rubbed off the paint from the two traces (green) and soldered the leg directly to it from the component side. if you want to build your own - here's the label I've printed out to stick on mine: 2048 '4K' v1.0.BIN
  6. what about checklng the stack pointer after reset - it's different for 2600/7800: FF on 7800, FD on 2600 http://atariage.com/forums/topic/261488-reset-sp/
  7. hi, just saw your replies (didn't get an automatic notification via atariage - can I enable this somehow ?!) and just wanted to say that it's great to hear that you are changing Stella accordingly - I quite like the FE bank switching scheme myself. It's elegant to implement in sw while at the same time simple to build in hw - even automatically initializes the bank during reset since this triggers 1fe, too. If I ever write a <= 8K 2600 game it'll certainly be an FE one Thomas
  8. Hi, just wanted to write something here when I saw this, esp. since I am not only located in Germany but also in the area where the people involved in the project are based. So I was lucky enough to speak frequently beforehand with several people involved in this project. Plus I saw the finished cases on the 'DoReCo' party. Just to be clear: I have no involvement myself and didn't get one for myself yet since I prefer the older, breadbox cases simply since that's what I had as a kid. I myself think the cases are quite nice, very nice in the original beige color case. Depending on the color choice there are slight annealing marks a bit more visible in the plastic - which some people commented upon on local forums. The ones I saw were at the expected places - mostly at the back of the case - and more noticeable with darker colors. The SX color scheme showed this a bit less, the black one the most. None of this is a deal-breaker for me and I keep thinking I should drive those 4 km to pick up a black one or maybe the SX-colored one for myself.
  9. I've finally obtained a NTSC 2600 for testing and tried my Tiara hw out on it: while playing a whole bunch of different games I saw on this setup that the FE code was unstable: Decathlon and Space Shuttle crashed, Robot Tank glitched (very rarely) but Thwocker worked just fine. That surprised me a bit since much more complex things like AR or DPC(+) work. However, FE was troublesome before, last time on the 7800, and I never fully understood why certain timing changes helped so this didn't surprise me that much. So, I've tested again on 7800 and two 2600 PAL where everything worked except Space Shuttle on one PAL 2600 - sometimes it crashed which so far slipped through my testing. At this point I decided to entirely rewrite the code from scratch, not based on the documentation I saw before but using a simpler version that just checks rts/jsr access to the topmost stack by the order of the incoming accesses to 1fe/1ff. Again no luck - Space Shuttle or Robot Tank now work stable but Decathlon refuses to come up. I add/remove sanity checks (like whether the following adr. is the one it's supposed to be) but this doesn't help either, however it does expose a strong hint why Space Shuttle didn't work - a specific 1ff bus access pattern. Which gives me another idea, because I had a very strong gut feeling anyways that all I'm doing is way too complex: so, I ignore all documentation I might have read, e.g. that opcodes are detected on the bus (very unlikely Imo, never tried that) or that the previous cycles adr. is used, or the next ones. Because in hw the most easy thing to have implemented would have been to just wait for 1fe on the bus and always latch the next cycles data bit for the bank address line. And this is what I did and you know what: this minimal FE bus routine works flawlessly on all my consoles, including the 7800. This increases my confidence in my theory quite a bit so I've just got to ask: is there some proof that the FE bank switching method does use a more complex mechanism than waiting for 1fe (or maybe more adresses $1xy with xy even, you'd just have to ignore adr. lines). ? Because from where I am standing everything else seems to break one game or the other here. Thomas p.s. quite a long text but I thought maybe it's interesting to see how I attack something like this from a bus emulation point of view p.p.s. I've just hooked up all my consoles and successfully tried this behavior with all the FE games I've got, took a while...
  10. TomSon

    VecFever

    The VecFever also has a serial port - this standard usb is of a serial<->usb chip which fits neatly into the case, too, although it does get really tight in there. I've also added a (low-6809-cycle) way to access the serial connection via Vectrex cartridges.
  11. TomSon

    VecFever

    Well, I've got excellent news and a slightly less good one. First the less good one: it's vacation time and everyone is off to sunny and warm locations, including myself, for a while. The good one is that yesterday the cases were made - or rather the usb openings were drilled with a cnc machine. And they turned out beautifully; so the dimensions of the pcb and case, the precision of the cut - I'm a really picky guy but there's nothing I can faul there - they are just perfect. The plastic was borderline useable for cnc-cutting, even with coolant fluid over it all the time (and a knowledgable person fiddling with the process parameters) quite a few cases were destroyed. Still, I decided to get this over with and made probably all I'm likely to make for a while. Friends also sent me a few (semi-)transparent ones to try out - they are really rare in the moment but I wanted to try out the plastics, if some ever get available. Surprisingly those seemed to work better so I'm a bit more open to actually make another batch, if these ever get available. I've tried them out with the LED on the pcb but apart from the one transparent one I've got the results weren't really useable in Vectrex mode - you can hardly see the color of the LED under an orange or blue case. The blue one is more useable for USB-mode, the orange one almost once you know what 'blue' looks like there but my personal favorite is still just the black case. The ones I've made for myself before have a LED on the outside corner of the case, so it's still easy to see when in a Vectrex, I've put them in the photo with the colored ones so you know what I'm talking about. So, when I'm back from vacation (August or .maybe. early September, I'm a European so plenty of vacation time..) I intend to make them available - either just the pcb if you are a lucky owner of a transparent case already or want to use it as is. Or including a case- in that case I'll still add a LED, in case you want to add one yourself eventually. If you know you want to right away I probably can also drill the necessary 5mm hole for you - I just don't want to add the LED myself because so far it took me quite some time to get the LEDs in - adjusting the cabling and hot-glueing the LED in - and I'm not certain whether the cable solder points on the Led side would survive a really rough postal handling.. Thomas p.s. (the black ones in the photo below are just a few of the ones I've got now..)
  12. I'll try a similar approach to this modified kernel then, too, maybe it works on my 'bad' TIA..
  13. Great video to explain what I'm seeing: that's a very similar in-between behavior I am seeing on that TIA, only with 1-pixel offsets at the very start of the line. So only the first chars wiggle a bit until they descend into the stable, warm delay.
  14. Hmm, I thought the shift is still required but the gaps are handled via balls - might have misunderstood that. That's why I called this a '32 char' kernel, not a 128 pixel kernel but I did use the term 'bitmap' before w/o mentioning the gaps (since they are no problems here); so from now on I better call this just a char kernel. If this indeed is different for the sprite handling I might try it, too, if only to test it with a specific TIA I've got (and replaced) that's on the way to IC heaven: when it heats up, it starts delaying the very first sprite horz. by one pixel. This takes a few seconds when heating up - in-between output is erratic from scanline to scanline. Thing is - I cannot decide whether the TIA is actually failing or the kernel only works on a subset of chips reliably. It's not a real problem for the Tiara since it can switch menu displays on the fly (already ntsc/secam/pal variants of four menu displays are in there) but I'd like to understand this better. Has anyone seen something similar ?
  15. Yes, the chars are in nibbles - you can also see from that source snippet that some are shifted, just like the 'normal' 32 char kernel setup. In theory a 650x could construct a bitmap function easily, too, if you had enough RAM (32K via e.g. 3E would be sufficient) but it's much faster just letting the Tiara processor auto-generate the code when the 2600 isn't drawing anything into the menu F4 cartridge.
×
×
  • Create New...