Jump to content

decle

Members
  • Content Count

    287
  • Joined

  • Last visited

Community Reputation

697 Excellent

About decle

  • Rank
    Moonsweeper

Profile Information

  • Custom Status
    0x10 bits or less
  • Gender
    Not Telling

Recent Profile Visitors

6,935 profile views
  1. Hey Guys, Tony at Hard4Games has posted an update on the prototype boards: @intvnut, @Lathe26 and I have been working with Tony to try to understand quite what he has. It's a bit intriguing. First the bad news - the carts don't hold some long lost version of Infocom's text adventure. The first cart is essentially a copy of the 1979 copyright version of Poker & Blackjack, with the title changed to "GEMINI GAMES+TOYS". This is the only difference in the ROM and it plays exactly the same as the retail game: The second cart is just weird. It contains four 2K x 8-bit EPROMs. @Lathe26 discovered that three of these ROMs come from the Intellivision retail version of Donkey Kong. They contain the upper 2 bits in the address range $5000 - $57ff and all 10 bits from $5800 - $5fff. The fourth EPROM contains the lower 8-bits the retail release of Pitfall! in the range $5000 - $57ff. Like the Poker cart the only change is to title screen, which looks like this: This means that the changes are limited to the single Pitfall! derived ROM. The mismatch of ROMs is very strange. Whilst it is not obvious (at least not to me) that this kind of mix and match should work, even as far as getting a title screen to work, it does explain why the game does not get any further. The current tentative hypothesis is that these carts were part of an initial investigation into developing Intellivision titles. They originate from an engineer (now sadly deceased) who worked for both Sanders Associates and Milton Bradley. The boards themselves are a Frankenstein hybrid of retail PCBs and hand wired prototypes. They remind me of lab boards I've hacked together when doing initial product development. The fact that they use wire-wrap, rather than strip board or veroboard might suggest the developer was working in a commercial environment, rather than a hobbyist, as wire-wrap is quite a bit more expensive. @Lathe26 is currently working to draw up the circuit diagrams. If we consider the three games used on the ROMs we see something potentially interesting. Whilst the title screens on all three games could be changed with just a hex editor, and without the need to disassemble and reassemble the games there are some differences: Poker and Blackjack - as a Mattel title with a standard title screen, only the title and copyright can be easily be changed. And it is not super obvious how to change the copyright date. Donkey Kong - it's obvious that DK doesn't use a Mattel title screen, and all the text on the screen can easily be changed. However, the blank lines between the text can't. Pitfall! - is not as obvious that it has a non-Mattel screen. However, when you examine the ROM, it is clear that essentially everything after the first three lines (everything from Activision onwards) is just text in the cartridge, including all the whitespace, and as such it can be changed with just an editor. So does this represent development progression? Starting with Poker, tinkering a bit, working out what can be done easily is quite limited, switching to Donkey Kong, finding more flexibility and finally looking at Pitfall!? It will be interesting to see whether @Lathe26's work on the circuits shows a similar progression. The other things to notice are firstly that although the lower part of Pitfall's title screen is effectively free-form text, the changes made largely adhere to the original layout: As @Lathe26 observed, the longer Planetfall title is pushed to the left in order to maintain alignment with the (tm) rather than moving the trademark right by a character to centre everything. However, the developers did understand the free-form nature of the screen as they made Planetfall longer than Pitfall! (this is not something that could be done with either Poker or Donkey Kong). Secondly, the copyright date has been changed from Pitfall's 1982 to 1983, and this might be indicative of when this work was done. If this was a third party's first baby steps into Intellivision development, to have put together these boards the developer must have had access to ROM images. This suggests that they also developed, or had access to, a tool to dump the non-standard GI ROMs that the Intellivision uses. So, on one hand the lack of a game on these boards is a tad disappointing. However, they seem to provide an fascinating glimpse into the initial development work on Intellivision titles by a third party, and I think this is really cool. I'm hoping we can find out more of the story behind their construction (for example, who they were done for and who Gemini Toys+Games was - the internet does not seem to be very forthcoming). I suspect it might be very interesting.
  2. Anyone heard of someone porting or writing a game called Planetfall for the Inty? Hard4Games seems to have a couple of very homebrew handwired proto carts: They look like they might be Inty t-cart type circuits using standard EPROMs butchered onto a stock cartridge PCB. The EPROMs have 24 pins so they are probably 4K 2732s, this suggests the boards might be contemporary as more modern boards are likely to use larger 2764, 27128 or 27256s. As there seem to be 4 EPROMs I think the boards will support games of up to 8K in size. I've only skimmed the stream, but they don't seem to get very far or give a good description of the boards. Before someone asks, at one point the host does mention the ROMs have been dumped. Hopefully we will learn more in subsequent videos, and perhaps they hook up with Joe and we might be able to find out a bit more about the circuit. I was a bit worried this might be a C64 cart (As we know C64 carts are physically similar to Inty ones and Planetfall is the name of a text adventure that was released on the C64). However, this close up of the cartridge PCB does seem to show an Inty board, and at one point it is possible to read LSB / MSB on the EPROM stickers suggesting they are being paired to give a 16-bit data word required by the Inty:
  3. Yup But possibly they did in the past? You mean a bit like this?... Clearly this does not address how you would test your game once it is assembled using a mid 80s, 286 class machine. To do this would require a hardware test harness like the MAGUS or Blue Whale.
  4. Unfortunately, there are no contemporary, commercial devkits along the lines of the Frob-26 for the Intellivision that I'm aware of. Technically, there is no reason that something like the Frob could not have been put together to run on a disk based home computer like the Apple II. However, as @Bruce Tomlin said, owing to Intellivision idiosyncrasies it would probably have been more complex to do than the 2600, and access to documentation of the EXEC is likely to have been problematic. In practice, the Frob does not seem to have been a commercial success, so given the significantly smaller number of Intellivisions sold and greater devkit complexity, it is perhaps unsurprising that no Inty equivalent appeared. As @nanochess has said, each of the 3rd parties had their own in-house devkits. These were typically based on a PDP-11 or VAX mini-computer, which were popular small, 16-bit multi-user business systems of the time. Both Mattel and APh used them for Intellivision development, so if you were poaching developers they would be familiar with them . GI also sold a commercial CP-1610 assembler/linker for the PDP-11, which would have been a leg up. @mr_me is also correct that during the years of INTV releases (1985-1989), they used a PC based system put together by David Warhol and Scott Robitelle. This is perhaps the closest system to what you are looking for. The old Intellivision Productions Magus-II page might give a hint as to the specs of this system: https://web.archive.org/web/19980613190636/http://www.makingit.com/intellivision/magus.shtml We can see that the requirements were for an "IBM-compatible PC (286 or better, DOS 3.0 or better) with an available 13-inch PC board slot". This suggests an IBM PC/AT class machine with 16-bit ISA slots, which just happens to have been released about a year before the first INTV title (the IBM Model 5170 launched August '84 with DOS 3.0). Such a spec was very outdated when the MAGUS-II was being put together in 1997, so perhaps this is really a reflection of the target platform for the original INTV devkit? If anyone has more information it would be very cool to expand the documentation of both the INTV devkit and the cancelled MAGUS-II to the development systems documentation.
  5. Hey all, This work was done as an entry to the Fall 2019 RetroChallenge, however, as some of you might be aware this instalment of the competition was aborted. When RetroChallenge rose phoenix-like in April 2020 I asked Mark Sherman if my work might be considered as a retrospective entry and he was kind enough to agree. Well, I'm very pleased to announce that Raiders of the Lost Debugger won...! http://www.retrochallenge.org/2020/08/202004-05-results.html ...in the "Weirdest" project category, which as anyone who knows me will be aware, is the highest honour anyone can pay my work. I am stoked that it is named next to projects by hard core people like @paulrobson. Cheers decle
  6. Hey all, My idea for the 2020 IntyBASIC competition needed some code to read and write ECS files on tape and scan the ECS keyboard. Having put something together, I thought it might be useful to others, so here it is with some minimal examples of how to use it: ecslibs.zip Hopefully the libraries are written generically enough that they might be useful to others. I believe everything should work on both JzIntv and real hardware. Credit where it is due, the core keyboard scanning routine is derived from @intvnut's work, documented here: And the tape handling was reverse engineered from the ECS emulation in JzIntv and some hardware fiddling. Thanks Joe. I've also included a simple single screen ECS editor as a slightly larger demo showing how the libraries can be integrated. You can see it in operation on real hardware here: Cheers decle
  7. Hey all, As I think is reasonably well-known Daniel Bass pioneered colour multiplexing for use on the Intellivision when he was creating Tower of Mystery / Tower of Doom. This technique, named "bi-color" by Daniel, gives the illusion of more than 16 hues by toggling the colour of tiles every frame (1/60th second). The persistence of the slow phosphors on old CRTs (which were geared to smoothing the 60 fields/second of interlaced NTSC TV into 30 frames/second) would then blend the two basic colours into a third hue. Well, it turns out that quite a bit of work was done on this, which was then written up in an internal Mattel memo: rainbow.pdf As always, a hat tip to Daniel and Karl Morris for their work, and to Tom and Braxton at UCI for sharing this document from the BSR archives. As you can see, an extensive exploration was done of the 240 new colours that the technique afforded, looking at how stable they were and comparing them with standard Pantone shades. Talking to Daniel, this analysis was completed by Karl. Daniel then wrote the program RAINBOW to demonstrate some of the "best" colours that Karl found and allow developers to test how they interacted with different background colours as the level of flicker could vary significantly. We think that the original RAINBOW is probably lost to time, however, I thought it might be fun to try to re-create something similar based on the description in Daniel's instructions to show off the colours that Karl found. The results of this can be seen below (Warning - some background colours result in lots of potentially seizure inducing flicker - this is not nearly as bad in real life without YouTube doing its thing. You also have to force YouTube to 1080p60 to see the bi-color effect properly) rainbow.zip The zip archive above contains both the ROM and the source code of the RAINBOW replica, which is largely written in IntyBASIC. Instructions for the use of the ROM can be found on page 2 of Daniel's memo. As I come from the land of PAL, if anyone has an LTO Flash and a CRT I'd be very interested in seeing a video of the program in action on authentic US hardware. Whilst I have talked to Daniel about RAINBOW, there are a number of areas where artistic licence has been applied in putting together the replica. As a consequence, whilst the colour changing algorithm is replicated and should display correctly on an NTSC CRT, the UI is not accurate. Specifically, Daniel does not recall trying bi-colors on MOBs, so it is unlikely that the pattern on the right of the screen was animated (I left this in for reasons that will become apparent below) and the following are not known: Whether or not the columns and rows were labelled The shape and size of the colour swatches on the left side of the screen What static pattern was shown on the right side of the screen to illustrate the selected colour against the current background The shape and colour of the cursor How the cursor moved (whether it glided smoothly or jumped from one swatch to another) Whether any information was reported about the selected colour Having played with the RAINBOW replica a bit using JzIntv, I have found it takes JzIntv / Windows / Linux a few seconds to sort their respective lives out and get to a point where the frame rate stabilises and the flicker is minimised. Once things settle down, I agree with Daniel that the bi-color effect works well with small areas of the screen (and by extension probably less so with larger solid blocks of colour). However, I would add that when combined with the motion of a sprite the effect is very convincing, even in an emulator running on a modern monitor. Therefore, the bi-color technique might be best suited to use with MOBs in fast moving action games. This may already have been noted elsewhere, but a small extension to Daniel's technique also seems plausible. It may be possible to get 3 hues for the price of 2 MOBs with minimal flicker by using a single basic colour on one MOB, and then multiplexing a second MOB between two different highlighted areas over the top of the first, as shown below: For this to work one of the two components of each of the MOB2 bi-color shades would have to be same as the basic colour used for MOB1, and MOB2 will need to be repositioned and / or reprogrammed between each frame. Anyway, despite the replica UI being less than accurate, I think this is another nice little glimpse into the kind of tools and techniques that the Intellivision developers were using towards the end of the Mattel era. Thanks once again to Daniel, Karl, Tom and Braxton. Cheers decle
  8. Yes, there is and happily it is trivial. All you need to do is write a value to one of the GRAM alias addresses (e.g. $3c00) and then read from the equivalent base GRAM address (in this case $3800). If you can see the data you wrote there is no additional GRAM. If you want to be super careful you clear the base GRAM address first. So something like: wait poke $3800, $00 poke $3c00, $aa if (peek($3800) = $aa) then ' No additional GRAM :( else ' Party on dude! :) end if This is what I did when implementing the "Tutorvision" mode of Studiovision (I should note that StudioVision was written in CP1610 assembler rather than IntyBASIC so the actual code is not exactly the same, but the principle is). Here is StudioVision running on a stock Inty: And it running on a "Tutorvision" within JzIntv: Same ROM image, just a JzIntv flag change.
  9. Hmmm, I'd be cautious about over thinking this guys. Remember that there were a total of 13 and 12 submissions to the previous contests. Whilst I understand the objective of increasing participation by encouraging specialisation, I suspect that adding constraints on entry, such as team membership, will reduce rather than increase submissions. And having multiple categories will naturally fragment the pool of entries. Perhaps optional awards such as "Outstanding Noob", "Best Solo Effort" or "How Does That Fit That In There?", if the judges feel an entry is particularly deserving might be better? That said, regardless of what is decided, I had fun last time and I'm interested in entering again. However, I should note that I feel my 2018 entry was a bit too mainstream, heck even @cmart604 thought it was worthy of comment, and as a consequence I think it got way too many marks in a number of categories. This is something I would hope to address this time around. Cheers decle
  10. Thanks for giving the script a bash, sorry it didn't work first time... TL;DR Summary: There was a problem related to garbage at the end of some Triple Challenge ROM images. This new version should work around this problem and is simpler to use as it generates its own quadChallenge.cfg (the .cfg file found in the previous version is no longer needed): quadChallenge.zip Details for the Curious: Following a bit of offline diagnosis with @Zendocon, we have discovered that his problem was down to variations in ROM images of Triple Challenge. Like most copies commonly circulating Zendocon's ROM contains junk at the end of the .bin file. This appears to be the result of the original dump including the state of the RAM used by Chess. The initial state of this RAM is irrelevant and it shouldn't really be in the ROM image. My copy of Triple Challenge has been "filtered" to contain just the 16K decle ROM that holds the game code (8K for Chess and 4K each for Checkers and Backgammon). Unfortunately, I had forgotten about the longer 44KB version of the ROM, and in its original form the script generates a corrupt quadChallenge.bin when used with this more common image. The enhanced script provided in this post corrects the problem by taking a copy of Triple Challenge and capping it to 32KB (16K decles), before concatenating Reversi onto it. This should fix any Triple Challenge ROM compatibility issues. The script also leaves the 32KB ROM-only version of Triple Challenge in tripleChallenge32k.bin / .cfg. If you have the larger 44KB image, you might want to replace your copy of the ROM with this "cleansed" version. The 32KB image is functionally identical to the 44KB version and is technically more correct. Finally, thanks to some ROM merging magic from @intvnut, the quadChallenge.bin generated is now a clean, minimal version that does not need to be patched at start-up by a complex quadChallenge.cfg. Hat tip as always to the master of Inty tech. If there are any other issues or feedback, just shout!
  11. It's sunny here at the moment, but challenge accepted! quadChallenge.zip Within this zip archive you will find a script that should work on Linux (and possibly MacOS or other POSIX environments) and an JzIntv configuration file. When supplied with a JzIntv install, Reversi and Triple Challenge .bin files, the script will use the assembler and disassembler in JzIntv to patch Reversi and create what Intv intended all along - Quadruple Challenge! To run the script just do following (note that the path to JzIntv is to the root of the install not the actual JzIntv binary): quadChallenge.sh <path to JzIntv install> <path to reversi> <path to triple challenge> for example: quadChallenge.sh path/to/jzintv games/reversi.bin games/tripleChallenge.bin Then just put the included .cfg file next to the quadChallenge.bin file that the script creates and fire up Quadruple Challenge using JzIntv, fresh from 1986 A little birdy tells me that is not the only thing to be looking for in the Bump N Jump codebase cheers decle
  12. Listening a bit more closely to Keith's video I think we can hear that this is a recording of Keyboard Component software. I have isolated a small section of the audio which covers the Stock Market and applied some compression in this example: demo1.mp3 We are not interested in the narration, just the "quiet" periods of the tape. For the first 5 seconds there is quite a bit of background noise with what sounds like a tone mixed in with it. Then, between 5 and 6 seconds, the tone stops. At 6 seconds it restarts just before the narrative, at which point it is drowned out. Once the discussion of the stock analysis program finishes the tone can be heard again through to 28 seconds at which point it stops for a second before restarting at 29 seconds. This tone in the background tape hiss is the sound of the demo cassette software being loaded, bleeding through from the data track. The short 1 second gaps in the tone are the "inter-record gap" or IRG between blocks of software. We can hear similar bleedthrough in other recordings of Keyboard Component cassettes. For example, in this short section of the audio track of RonTheCat's copy of Conversational French: cf1.mp3 So I think it is quite clear that the demo is probably a recording of K/C software running. Unfortunately, despite knowing the frequencies that K/C software uses I don't think Keith's recording is clear enough to be able to isolate and extract the software from it; at least it is beyond my audio skills. Additionally, if we compare the timing of Keith's video with the demo cassette MERT file we can infer that the /TIME directives in the file, which control the placement of data and timing, are probably measured in 1/10ths of second: I think this means that if this level of accuracy could be achieved reliably, it would have made it possible to produce lip-synced animations, that according to Wikipedia would have been a reasonable quality. Now that would have made for an impressive demo in 1980! This is an interesting observation. I'm not sure we can say definitively that this video is a recording of Jack LaLanne or Conversational French, although it may be representative of the titles. Just like the snippets of Basketball or Math Fun in the split screen section of the demo, they may be caricatures put together using PicSe. The demos of K/C software are likely to be more accurate than the split screen section because both titles were written using the same PicSe framework that seems to be used to construct the demo. Perhaps the video should come with a "not in-game footage" warning overlaid in K/C text? Here are the sections of original game audio that were used in the demo, again both taken from recordings of RonTheCat's tapes. First Conversational French: cf2.mp3 Ignoring the reordering and selection of just some words from the lesson; the short bursts of "software" sound on the recording suggests that the graphics for each word might have been streamed individually. However, the demo cassette MERT file suggests that this is not how the software was structured here, with all elements of the French demo being lumped together with the Keyboard Component introduction as one large block of software: And here we can see the constituent parts of the French demo (FRDEMO), including what I suspect are the graphics for la chemise and la robe: And here is the Jack LaLanne situps section. It comes as the first exercise in what seem to have been regular fitness tests used to track your progress. As you can hear, Jack recorded several versions of the introduction to provide some variety: jl1.mp3 More information about the structure of K/C cassettes and the software used to construct them can be found in the latest update to the Intellivision development description (as well as plenty of other, hopefully interesting, stuff ).
  13. Hey all, After a long hiatus I have an update of the development tools doc. Hopefully it has some new and interesting bits and pieces. Get it while it's hot: intellivisionDevelopmentBackInTheDay-20200612.pdf This time the big ticket items are: Lots of Datawidget goodness... (p8-p16) First contemporary image of (half) a Datawidget courtesy of JoeZ and Twitter First modern images of both the exterior and interior of a Datawidget More details of the Datawidget, Dopey and Crosspatch implementation Contemporary picture of the Mattel Graphics Development System and overview (p19) Initial overview of MERT, GERT and MODIT, the tools used to create Keyboard Component tapes (p6-p8) Summary of a previously unknown Magus debugger written by Bijan Jalali in 1982 (p21) More details on the Magus including its origins, the existence of an 8K version and common complaints from 1982 (p23-p25) Addition of a comparison of the Mattel development / debugging systems including notes written by Keith Robinson for an updated YFTE (p30-32) Images and brief comparison of two additional T-Card designs (p33-p35) Ask and ye shall receive (after a long wait ) I think that some of this is covered in the latest PlayCable Technical Summary. It looks as though the communications were run using 8E1 (8 bits, even parity, one stop bit). From the pictures we have it's hard to tell whether the 13.98KHz baud rate of the PlayCable, which was derived from the Intellivision's 3.58MHz clock, was changed by Joe and Dennis (I carefully glossed over this point in the write up ). Although 13.98KHz might be close enough to the standard 14.4KHz baud rate to work (<3% error), it doesn't seem to be a common speed and I don't think many cards of this era supported it. Unfortunately, we don't know anything about the software protocol used for communication. I live in hope that Joe Jacobs might provide us with a dump of the EPROM one day. It would provide a great reverse engineering project and answer alot of questions. Anyway, I think that's about it for this one. As always all feedback and corrections are welcome. Cheers decle
  14. Nice! I've probably been a bit slow here, but I just had a bit of a lightbulb moment. Whilst working on an update of the development doc recently I came across this MERT file which Tom and Braxton found in the BSR archive. MERT is one of three tools (MERT, GERT and MODIT) that APh wrote to create Keyboard Component cassettes (more on this in the programming forum soon). This MERT file suggests the contents of the demo cassette might be: Curtain and Intro Master Component Baseball Blackjack Space Battle Keyboard Component / French Exercise / Jack Lalanne Stock Analysis Split Screens Credits Closing Curtain Comparing this list with the contents of the Keyboard Component demo video posted by Keith back in 2007 there seems to be a pretty good match: The "Next Show Starts Shortly" message is probably explained by the time required to rewind the tape to the start. Today's lightbulb for me was that Keith's demo probably isn't an overdubbed and edited together piece of video as I had assumed. Rather it is probably a single take recording, inclusive of the audio commentary, of the K/C demo cassette in operation (yes, yes, I know, I didn't read the description on the video and I'm slow). And the MERT file might be a small part of the software used to construct the tape. As such, I think this might be the only contemporary recording of working Keyboard Component software. It also might represent what is on Steve's tape
  15. Thanks for the kind feedback. I'm glad you guys like the game. If you haven't done so already, I'd encourage you to give the demo/teaser a go using JzIntv or the LTO Flash (you can download it from the top of this thread). The zip file includes a ROM with two playable levels, along with instructions and overlays. For those that like a challenge, let me throw down the gauntlet. Is it possible to score more than 1389 on level 1? I thought I had also posted a pretty good score of 1354 on level 2, that was until my son came along and trounced it. He then claimed that it "was not a perfect run" and he "could do better". Nothing like being pounded by a 14-year-old to put you in your place. Now that is a blast from the past! I remember playing Kye on Windows 3.1. I agree, XOR does have a similar feel to Kye and obviously it also has elements of Boulder Dash and its clones like Repton. Although, the strictly turn based nature of XOR and lack of random elements in the game mean it feels even more of a puzzler than an action game (I suspect it also makes it much easier to program ). Unfortunately, because the game uses Mattel-style paged memory, XOR cannot be packaged as a .rom as the file format does not support this feature. The .int format is identical to the .bin file provided, just with an alternative extension. As noted in the instructions, XOR makes use of JoeZ's JLP extensions (at the moment just for additional RAM, but shortly also for flash storage of hi-scores) so as far as I'm aware it will only work on JzIntv and the LTO Flash. Once again, thanks for your interest and comments. Keep them coming, perhaps with some high scores.
×
×
  • Create New...