Jump to content

decle

Members
  • Content Count

    254
  • Joined

  • Last visited

Community Reputation

558 Excellent

About decle

  • Rank
    Moonsweeper

Profile Information

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

Recent Profile Visitors

6,139 profile views
  1. This is great news, I'm looking forward to the results. I'm intrigued to see the complete font and how the real POPlexer handles "Sphinx Of Quartz, Judge My Black Vow". I think it's fair to say that POPlex-a-like does not do the best job I couldn't work out a way to get a full 4x4 tile font to fit into 64 GRAM characters, even if bits of similar glyphs like P and R are reused. It was also necessary to invent a number of glyphs, as they do not appear in cylondr's video: However, a look at the Intellivision catalogue suggested that, of the released Mattel titles, the most complex seemed to be "Blackjack & Poker" with 17 characters, and ignoring spaces, 11 unique letters. So, to keep things simple, POPlex-a-like applies a set of restrictions - a title can have no more than 20 characters, of which no more than 16 can be unique. It will be interesting to see what the real thing does with more complex titles like "Sphinx Of Quartz...", or The Dreadnaught Factor (180 letters long, with 28 unique characters!). It would seem that I spoke too soon about the completeness of POPlex-a-like, pride before a fall and all that. On watching cylondr's video again, the original Poplex-a-like was missing the jingle on starting a game, the "message from Marketing" when the demo cart is not plugged in and the all important "key clicks" when changing games. The following update adds all of these "features" and reduces the delay before kicking off the demo to 10 seconds: poplex-a-like.zip As you can see in this short clip: I think this gets close to what is shown in cylondr's video. The font and sound are probably a bit off, and there are some unknowns, for example whether the game launch jingle plays when starting the demo cartridge, but I think it's a reasonable first second stab. Either way, it's an item off the rather lengthy list of half finished projects. Unfortunately, the PlayCable's menu works in a different way to the POPlex-a-like. Essentially it is more like a game than a hypervisor. Happily it is just software, and with a bit of work it can be transformed... Cheers decle
  2. It's rather more involved than the scripts, but yes it is possible, here you go: pcFrontEnd.zip Enjoy, Cheers decle
  3. Hey all, I'm looking forward to the results of the work started by @Lathe26 to document the POPlexer / Kiosk Component. In the mean time, I've finished off a work-a-like ROM, a POPlex-a-like if you will, that I started back in 2018. So here we go: The POPlex-a-like works as a simple front end for up to 11 games, just like the POPlexer. To play the currently selected game, just hit ENTER. To switch to the next game, tap the disk. Finally, to bring the menu back, just hit RESET on the console. Just like the real POPlexer, the POPlex-a-like will automatically start the ROM in the first slot if there is no input for 30 seconds. Unfortunately, it is not possible to automatically reset the console if a game is left running. You can download the ROM here: poplex-a-like.zip Obviously, I can't distribute the Mattel ROMs, so the version in this zip file has small stub programs that just display the title screen of each game for 30 seconds and then reset the console, restarting the menu. However, I have included shell scripts to package up your game ROMs and generate stub programs for yourself. In putting this together it has become apparent that there are a number of interesting titles within Mattel's pre-1983 catalogue. This is before we get to weirdnesses generated by the ECS and third party titles. It will be interesting to see what the real POPlexer does with: Math Fun and Shark Shark - neither of these have EXEC title strings, the POPlex-a-like just displays them as blank titles, but will play the games. Backgammon - has exactly 10 characters in its name with no breaks. In the video the real POPlexer seems to handle this correctly as a single line title Burgertime! - has an 11 character title with no breaks. In the video the POPlexer seems to treat this is a two line title, but truncates the exclamation point. Lock'N'Chase and Maze-A-Tron - also have titles longer than 10 characters with no spaces. Neither game appears in the video, so with a bit of artistic licence the POPlex-a-like treats the quote and hyphen characters as breaking characters (like spaces), which means that these titles are split onto two lines. It's fascinating how something as simple as writing two lines of fixed pitch text yields so many edge cases. For those that are interested in how the menu system works, it makes use of Mattel style page flipping to change the ROMs with the menu resident at $7000. As always, any comments or corrections let me know. Cheers decle
  4. As some of you may have guessed I've been fiddling with IntyBASIC over the past couple of weeks. In the process, a port of John Hedley's BBC Micro puzzler XOR seems to have started taking shape: You play as a Questor and Magus (represented by shields) with the objective of collecting all the masks within a maze and making your way to the exit. Here is a video of the original: Cheers decle
  5. Hey Jason, Unfortunately, I don't believe it is possible to change the pitch of allophones on the Intellivoice. This is a bit of a shortcoming, as it prevents inflection for questions, and is a barrier to singing. The richer sounding voices on Mattel's games resulted from creating custom speech samples. These are much more complex to work with (as with most things Intellivision, JoeZ is your man) and can't be used in IntyBASIC at this time. I'm not sure if they support pitch shifting, I suspect not. It's a shame, as I think with a little more flexibility, lots of fun could be had with the allophones: daisy.zip It's also kind of weird, because the need for inflection was recognised from the very first speech synthesizers, like the Voder, which dates back to 1939!: Clearly, none of this would have prevented the much needed tie up with Texas Instruments and The Electric Company to create the highbrow Mattel edutainment title, The Electric Company Intelli-Speak & Hell snh.zip Cheers decle
  6. Ever wanted to "play" the Intellivoice using an ECS synth keyboard? Well now you can: I'm not going to claim this is an original idea, because it's absolutely not: But now you can let loose with your allophones without the need to break out your soldering iron. You can find the ROM and IntyBASIC source for this nonsense in this zip file: sns.zip This should be compatible with both the LTO FLASH and JzIntv. Obviously, if you're going down the hardware route, you'll need both an ECS synth and Intellivoice. There is one small thing that might be of use to others, Speak & Synth? includes an IntyBASIC port of JoeZ's ECS synth keyboard scanning code. Enjoy! decle
  7. Will the upstart from Plastics Electronics prevail over the might of Wataggi? Got to love YouTube recommendations I like the way your developer downgrades from an Xerox Alto to an Apple II. And I wonder if the market crashes in '83? For those that are curious, it looks as though City Game Studio can be found on Steam (no affliliation or recommendation implied, I've not played it). Cheers decle
  8. Hey Guys, Thanks for all your thoughts, pointers and examples. It is much appreciated. I hope that I can put together something that will enable the construction of "instruments" as rich as these, whilst still being accessible to musicians and programmers. So it looks as though most of the other AY-3-841x work takes a more "sample" based approach than I have. Instruments seem to be defined as a sequence of volume and pitch variations that are blasted as the PSG. Taking the IntyBASIC implementation as an example, the instruments are defined using 24 volume and optionally 24 pitch samples: Although Oscar describes the first 8 samples as being "attack" and last 16 as "sustain", by my reading of the code it might be better to describe the first 16 samples as being the "setup" and the final 8 as the "loop", to use Arduino terms. The first phase is a one-shot and, if reached, the second is repeated until the note finishes. I've separated the two phases in the plots above. The IntyBASIC implementation is also really useful in highlighting a couple of differences in how sINThY is implemented. The most obvious is that the sINThY "instrument" definition is abstracted into 10 values, rather than 24 or 48 samples. I hoped the result is more intuitive to musicians, but it comes at the cost of some flexibility in what can be generated. So, the obvious question, is this more intuitive route and is the loss of flexibility a price worth paying? Or should I be using the more common sample based approach to define envelopes? Next, if we look at the way in which IntyBASIC handles pitch vibrato we see that the amount of period change is constant with the pitch of the note. This means that vibrato is stronger at high notes than low notes, most clearly heard on the clarinet, for example in the extreme: DATA 60 MUSIC C2X MUSIC S MUSIC - MUSIC C7 MUSIC S MUSIC - MUSIC REPEAT Because sINThY allows greater change in pitch than the native IntyBASIC instruments (up to +/- 2 tones), more work has gone into keeping this change constant across the range of notes played, although I'm still not happy with the results. Am I correct to try to manage the change in pitch in this way? Currently the pitch change is a nasty mathematical adjustment of the period value. This leads to the waveforms being musically asymmetric and not necessarily peaking at chromatic tones. It might be better to calculate nearest periods for all the eighth-tones as we currently do for semi-tones and make the pitch shift of a whole number of these. So a triangle wave of amplitude 8 would start at the note played, go up a full tone then down to a full tone below the note played and return, with each change in frequency being an eighth-tone. What do you think, would this be more "musical" and make more sense to a musician? Finally, we have the handling of volume, somewhere I think the way sINThY is implemented might make things easier. Because sINThY has to handle velocity sensitive input it treats loudness as an attenuation from a loud baseline, rather than volume relative to silence. This makes it easy to apply volume envelopes to the quieter input without them becoming silent early, and therefore, shortening notes. The only downside at the moment seems to be that the "sustain" parameter has the opposite sense to that normally used (being the attenuation from the maximum attack rather than the volume of the sustain phase). As always, your thoughts, opinons and experience would be much appreciated. Cheers decle
  9. Hey guys, For the past six months I've been distracted by other projects and this thread has been neglected. However, recently I have had a chance to put a bit of work into the first stage of sINThY, the software synthesizer for IMDI: This attempts to follow the principles of some of the low end analogue synths such as the Korg Monotron or Volca Keys (before you get your hopes up, I think the lack of a VCF to control the fundamental waveform limits what can be done). If you fancy giving it a go for yourself here is the ROM, along with a keyboard hack file that makes things much easier when using JzIntv: sinthy-20190411.zip As a non-musician, I'd be very interested in feedback from the musos out there. I feel as though I'm struggling to come up with "interesting" modulations. Cheers decle
  10. Hey all, Here we go, bit of a bigger update this time. Within the BSR archive there are a number of technical bulletins covering the period from September 1982 through to October 1983. Once again, Tom and Braxton have kindly scanned these for us. The bulletins seem to have been memos sharing updates from the various infrastructure and support teams with the group as a whole. They cover many aspects of development, including tools for programming M-Network games for the Atari 2600 and Apple II; and also Aquarius work. The cool thing is that, because they're dated, we can put together a bit of a chronology. As a consequence, I've updated the development description again with a load of additional details and references to the specific bulletins that provide supporting evidence: intellivisionDevelopmentBackInTheDay-20190329.pdf The main changes this time are: page 11 - Added references to the use of HP-1000 machines for speech processing purposes page 12 - Inclusion of information about Mattel using Nuvatec tools including assemblers on the VAX page 12 - Addition of a section on Dr Color to the Mattel chapter pages 14-15 - Some details on the Magus architecture, implementation, memory size and tools. Plus the introduction of MEGAS as the more common name pages 15-19 - Updates to the Blue Whale test harness section, including feature evolution and corrections to the architecture page 22 - Section on Mattel's tools and stance on reverse engineering competitors' code Last week I stumbled across this advert for the APh Datawidget from 1980, which I think is rather cool and I've added to page 7 (bonus marks for the first person that can tell us who currently is resident at 285 West Green Street and whether the phone is connected) Unfortunately, if anyone needs a summer job, although it looks as though you might have a few days to prepare, I think in reality you might have missed the opportunity As always, all feedback is most welcome. Cheers decle
  11. Hi everyone, I think some of you may be aware that two academics from UCI Irvine, Tom and Braxton, are currently writing a book on the history of the Intellivision. What you might not be aware of is that JoeZ and myself have been helping them with a little technical consultancy here and there. As part of their work Tom and Braxton have been granted access to the BSR document archive that was amassed by Keith Robinson. It turns out that this is a bit of a technical goldmine. The BSRs have kindly given permission for some of these docs to be reviewed and shared (many thanks guys). So here is the first document of interest to this thread, the APh Datawidget Users Guide: aphDatawidgetUsersManual.pdf This describes the architecture and use of the Datawidget in general, and its Intellivision incarnation specifically. This confirms much of David Rolfe's overview as recorded in the development description and provides lots more details. As a result of this I have updated the development document: intellivisionDevelopmentBackInTheDay-20190321.pdf I should have some further updates as we get more details. As always any corrections or additions please let me know. Cheers decle
  12. Kudos! This is a wonderfully original and cool way of demonstrating the ECS serial functionality. I can see I'm going to have to turn the insane dial up a notch or two on future projects
  13. Wow that was quick! Cool, thanks for taking the pictures. Here is a quick bit of analysis: Green chips are confirmed, yellow are tentative and red are currently uknown. Connectors are in blue. The large chip is a RO-3-9502 which is a 2K decle ROM that also contains an interface to standard memories. In this case there are two such memories fitted, 2 x 2716 EPROMs. These are 2K bytes in size, so the program within the switcher could be up to 4K decles in size. Hmm I wonder if we could use an LTO flash with suitable software to dump the contents of this? As I mentioned on the other thread, there are a number of images of both the inside and internals of the switcher / poplexer at the Intellivision library. It is interesting to note that this unit does not have the EPROMs fitted like your machine does, meaning it only has 2K decles of controller program: The 8T245s are pin compatible with 74LS245 octal bus transceivers, so these are probably just buffering the Master Component's address/data bus. Much of the rest of the known chips are standard glue logic. Probably doing bits and pieces of interfacing / cartridge switching and implementing the watchdog timer. The NE654 (top left) is a bit of an enigmatic chip. It looks as though the part number has been reused and it is now a 24pin Dolby controller. I don't seem to be able to find a DIP-16 chip with this number. The unknown fat 24pin chip above cartridge slot #6 is also interesting. Looking at chip dates it seems that your switcher was made somewhere after week 40 of 1981. If you take further photos of the chips we're missing I'll add them to the diagram. Thanks once again decle
  14. Hey Krslam, Apologies for the off topic post. However, about a year ago I did a bit of a write up of the functionality of the kiosks, largely based on this video: Since then, I found that the Intellivision Library has some images of the internals of the switcher, including this one (why is it that the technically most interesting image is always the last one on the page ): This picture is interesting because it suggests that the top right connector, which is marked as being "for Intellivoice use" is a male card edge, which is rather strange: Anyway, while these pictures are great, unfortunately they're not quite detailed enough to be able to identify the parts on the circuit board (including the really interesting looking big 40pin IC ). It would be really cool if you could post more / better images of the circuit within your switcher to the main kiosk feature thread, especially any that allow the part numbers to be read from each of the ICs on the board. I'm thinking more like this image of a t-card (click to see full detail): With images like this we can have a stab at reverse engineering the details of how the switcher worked and document another little bit of Intellivision tech in a similar manner to what has been done with the Blue Whale development boards and PlayCable Please drop me a PM if you would like to discuss this more. Cheers decle
  15. I agree Joe, a really interesting intermediate level simulation should be possible in either IntyBASIC or CP-1610 assembly. Lol, as always there nothing new under the sun! It also looks as though Mikebloke might be blessed with good timing, always a good skill to have It seems Cole Johnson is in the process of reverse engineering the earlier AY-3-8500 also based on decap images by Sean Riddle and the work of the Visual 6502 project. He has done some great work (which made him one of the winners of the Fall 2018 RetroChallenge), including getting an online transistor level simulation up and running, well worth a read. One of the more interesting findings thus far is the identification of how game selection relates to internal circuit configuration. While the left player can have one or two paddles (main paddle and "soccer striker" paddle), the right player can have up to three paddles!? (main player, "soccer striker" and main player paddle repositioned for the squash game - the left player uses their "soccer striker" paddle when playing squash). The choice of game is decoded into configuration that may inhibit the drawing of one or more of each player's paddles. The cool thing is that by selecting "no game" (something that was typically prevented by the mehanical game selection slider, but can be done by driving the chip pins directly) no player paddles are disabled, leading to an undocumented variation of soccer called Handicap, where the right player has three paddles and the left player only has two. Like everything else, this is not new news... ...but I think it is interesting to find out how the behaviour comes about. It is also a small example of the kind of behaviour I was refering to, that can be trivial and really cool to implement by trying to understand and follow the architecture of the original system when implementing a simuation.
×
×
  • Create New...