Blogs
Our community blogs
-
Latest Entry
Dissecting Atari Display Lists
A while ago I was working on a project and needed to know where the Atari OS chose to create its graphics modes in memory. I ended up making a tool in BASIC XL that walks the current display list, and describes each ANTIC instruction.
The output looks like this below. The example is a dump of the GRAPHICS 2 display list which includes a text window:
Disassembled Display List (GR2)to its corresponding graphics lineand Scan Line...DL Byte Value Gfx Line Scan Line(s) TV Scan Line(s) Description======= ===== ======== ============ =============== ============$000 000 $70 112 $01 - $08 001 - 008 $08 - $0F 008 - 015 8 Blank Lines$001 001 $70 112 $09 - $10 009 - 016 $10 - $17 016 - 023 8 Blank Lines$002 002 $70 112 $11 - $18 017 - 024 $18 - $1F 024 - 031 8 Blank Lines$003 003 $47 071 $01 001 $19 - $28 025 - 040 $20 - $2F 032 - 047 Mode 7 + LMS (16 Scan Lines)$004 004 $70 112$005 005 $9E 158$006 006 $07 007 $02 002 $29 - $38 041 - 056 $30 - $3F 048 - 063 Mode 7 (16 Scan Lines)$007 007 $07 007 $03 003 $39 - $48 057 - 072 $40 - $4F 064 - 079 Mode 7 (16 Scan Lines)$008 008 $07 007 $04 004 $49 - $58 073 - 088 $50 - $5F 080 - 095 Mode 7 (16 Scan Lines)$009 009 $07 007 $05 005 $59 - $68 089 - 104 $60 - $6F 096 - 111 Mode 7 (16 Scan Lines)$00A 010 $07 007 $06 006 $69 - $78 105 - 120 $70 - $7F 112 - 127 Mode 7 (16 Scan Lines)$00B 011 $07 007 $07 007 $79 - $88 121 - 136 $80 - $8F 128 - 143 Mode 7 (16 Scan Lines)$00C 012 $07 007 $08 008 $89 - $98 137 - 152 $90 - $9F 144 - 159 Mode 7 (16 Scan Lines)$00D 013 $07 007 $09 009 $99 - $A8 153 - 168 $A0 - $AF 160 - 175 Mode 7 (16 Scan Lines)$00E 014 $07 007 $0A 010 $A9 - $B8 169 - 184 $B0 - $BF 176 - 191 Mode 7 (16 Scan Lines)$00F 015 $42 066 $0B 011 $B9 - $C0 185 - 192 $C0 - $C7 192 - 199 Mode 2 + LMS (8 Scan Lines)$010 016 $60 096$011 017 $9F 159$012 018 $02 002 $0C 012 $C1 - $C8 193 - 200 $C8 - $CF 200 - 207 Mode 2 (8 Scan Lines)$013 019 $02 002 $0D 013 $C9 - $D0 201 - 208 $D0 - $D7 208 - 215 Mode 2 (8 Scan Lines)$014 020 $02 002 $0E 014 $D1 - $D8 209 - 216 $D8 - $DF 216 - 223 Mode 2 (8 Scan Lines)$015 021 $41 065 JVB - Jump Vertical Blank$016 022 $58 088$017 023 $9E 158
.
All the numeric values are output as hexadecimal values first, and decimal values second.
"DL Byte" reports the instruction byte's offset from the start of the Display List.
"Value" is the Display List Instruction.
"Gfx Line" counts the number of text or mode lines of actual graphics output by the display list. Blank line, LMS, and Jump instructions do not count as graphics lines. (Yeah, kind of useless. What was I thinking?)
"Scan Lines" shows the starting scan line and ending scan line of the instruction as ANTIC outputs scan lines.
"TV Scan Lines" reports the starting scan line and ending scan line of the instruction. The reason for the difference is that the Atari's scan line generator doesn't start until the 8th scan line of the television.
"Description" is a text explanation of the ANTIC instruction plus any other options added to the instruction.
If I were to do this again, I think I would add a screen memory counter to report the physical memory ANTIC outputs with the text or map modes.
Here is the BASIC XL listing:1000 Save "D2:EXAMDL.BXL"1005 Fast1010 Rem DISASSEMBLE A DISPLAY LIST.1015 Rem RESULT APPEARS ON "D2:"1020 Rem JUST SET GMODE TO THE DESIRED1025 Rem GRAPHICS MODE AND EVERYTHING1030 Rem ELSE IS AUTOMATIC.1035 Rem A CLEVER PERSON COULD CHANGE1040 Rem HOW THE DL LOCATION IS1045 Rem DETERMINED AND SO DISASSEMBLE1050 Rem A CUSTOM DISPLAY LIST.1055 Rem1060 Rem DL BYTE, VALUE, GFX LINE, SCAN LINE(S), TV SCAN LINE(S), DESCRIPTION1065 Rem1070 Dim Scl(16)1075 For Loop=0 To 15:Read Scl(Loop):Next Loop1080 Data 0,0,8,10,8,16,8,16,8,4,4,2,1,2,1,11085 Rem1090 Gmode=0:Rem OS GRAPHICS MODE.1095 Dev$="D2:":Rem DEVICE STRING.1100 Rem1105 Trap 1880:Rem STOP DISASSEMBLY. CLOSE FILE.1110 Rem1115 Tmode=Gmode&$10:Rem TEXT OPTION.1120 Gmode=Gmode&$0f:Rem BASE GRAPHICS MODE1125 If ((Gmode<1) Or ((Gmode> And (Gmode<12))) Then Tmode=01130 Graphics Gmode+Tmode1135 Dl=Dpeek($0230)1140 Maxoffset=240*3:Rem MUST BE A LIMIT SOMEWHERE1145 M$="023456789ABCDEF":Rem MODES. $2 = "2"1150 Gline=0:Lastg=0:Rem CURRENT GFX LINE1155 Sline=0:Lasts=0:Rem SCAN LINE1160 Tline=7:Lastt=7:Rem TVSCAN LINE. FIRST ONE REPORTED WILL BE 8.1165 Scanlines=0:Rem SCAN LINES IN CURRENT INSTRUCTION1170 Jvb=0:Rem FLAG THAT JVB WAS SEEN TO END THE LOOP1175 Fname$=Dev$,"GR",Str$(Gmode+Tmode),"DL.TXT"1180 Open #1,8,0,Fname$1185 ? #1;"Disassembled Display List (GR";Str$(Gmode);1190 If (Tmode) Then ? #1;" + ";Str$(Tmode);1195 ? #1;")"1200 ? #1;"to its corresponding graphics line"1205 ? #1;"and Scan Line...":? #1:? #11210 ? #1;"DL Byte Value Gfx Line ";1215 ? #1;"Scan Line(s) ";1220 ? #1;"TV Scan Line(s) Description"1225 ? #1;"======= ===== ======== ";1230 ? #1;"============ ";1235 ? #1;"=============== ============"1240 For Loop=0 To Maxoffset1245 Rem DISPLAY LIST BYTE OFFSET1250 Vla=Loop:Gosub 1665:Rem DOHEX1AS3N31255 ? #1;" ";1260 Rem DISPLAY LIST BYTE VALUE1265 Dla=Dl+Loop1270 B=Peek(Dla)1275 Vla=B:Gosub 1700:Rem DOHEX1AS2N31280 Rem WHEN DUMPING ADDRESS BYTES1285 Rem SKIP THE REST OF THIS ... 1290 If (Dladr>0) Then Goto 1505:Rem SKIP REMAINDER OF PROCESSING1295 ? #1;" ";1300 Rem DISSECT INSTRUCTION1305 Dlins=B&$0f:Rem DL INSTRUCTION1310 Insmod=B&$f0:Rem INSTRUCTION MODIFIER1315 Rem TEST FOR JUMPS1320 If (Dlins=1):Rem PROBABLE JUMP1325 Rem FIELDS UP TO THE DESCRIPTION ARE BLANK.1330 ? #1;" ";1335 If ((B=$01) Or (B=$41)):Rem JUMP1340 Dladr=3:Rem JUMPS ARE 3-BYTE INSTRUCTIONS1345 If (B=$01):Rem DL JUMP TO ADDRESS1350 ? #1;"JMP - Jump To Address";1355 Else :Rem JUMP VERTICAL BLANK1360 ? #1;"JVB - Jump Vertical Blank";1365 Jvb=11370 Endif1375 Else :Rem ILLEGAL INSTRUCTION1380 ? #1;"Illegal Instruction";1385 Endif1390 Else :Rem BLANK LINES OR GFX LINES?1395 Rem TEST FOR BLANK LINES1400 If (Dlins<1):Rem A BLANK LINE INSTRUCTION1405 Rem GFX DATA LINE IS BLANK (OBVIOUSLY, SINCE NO RENDERED PIXELS)1410 ? #1;" ";1415 Scanlines=((Insmod&$70)/16)+1:Gosub 1615:Rem DOSCANLINES1420 Rem DESCRIPTION1425 ? #1;Scanlines;" Blank Line";1430 If (Scanlines>1) Then ? #1;"s";1435 Gosub 1830:Rem DOMODIFIERS1440 Endif1445 Rem DO REGULAR GRAPHICS LINES1450 If (Dlins>1):Rem EVERYTHING $2 TO $F1455 Scanlines=Scl(Dlins)1460 Gosub 1570:Rem DOGFXLINES1465 Rem DESCRIPTION1470 ? #1;"Mode ";M$(Dlins,Dlins);1475 Gosub 1830:Rem DOMODIFIERS1480 ? #1;" (";Scanlines;" Scan Line";1485 If (Scanlines>1) Then ? #1;"s";1490 ? #1;")";1495 Endif1500 Endif1505 ? #11510 If (Dladr>0) Then Dladr=Dladr-1:If (Jvb And (Dladr<1)) Then Loop=Maxoffset1515 Next Loop1520 ? #1:Close #11525 End1530 Rem1535 Rem DOGFXLINES1540 Rem FOR ANY NORMAL GFX MODE USING1545 Rem SCREEN RAM JUST INCREMENT THE1550 Rem LINE COUNTER. A BIT OF CHEATING1555 Rem HERE AS WE FALL THROUGH TO THE1560 Rem DOSCANLINES CODE ...1565 Rem1570 Gline=Gline+11575 Vla=Gline:Gosub 1700:Rem DOHEXAS2N31580 ? #1;" ";1585 Rem1590 Rem DOSCANLINES1595 Rem GIVEN THE NUMBER OF SCAN LINES1600 Rem UPDATE THE SCAN LINE COUNTERS1605 Rem AND PRINT THEM.1610 Rem1615 Sline=Lasts+1:Lasts=Lasts+Scanlines1620 Vla=Sline:Vlb=Lasts:Gosub 1765:Rem DOHEXPAIR1625 Tline=Lastt+1:Lastt=Lastt+Scanlines1630 Vla=Tline:Vlb=Lastt:Gosub 1765:Rem DOHEXPAIR1635 Return1640 Rem1645 Rem DOHEX1AS3N31650 Rem OUTPUT A NUMBER AS 3 DIGIT HEX, 3 DIGIT DEC1655 Rem INPUT = VLA1660 Rem1665 Ha$=Hex$(Vla)1670 Print #1; Using "/$!!! &&&",Ha$(2,4),Vla;1675 Return1680 Rem1685 Rem DOHEX1AS2N31690 Rem OUTPUT A NUMBER AS 2 DIGIT HEX, 3 DIGIT DEC1695 Rem INPUT = VLA1700 Ha$=Hex$(Vla)1705 Print #1; Using "/$!! &&&",Ha$(3,4),Vla;1710 Return1715 Rem1720 Rem DOHEXPAIR1725 Rem OUTPUT ONE OR TWO NUMBERS AS1730 Rem 2 DIGIT HEX, 3 DIGIT DEC1735 Rem IF SECOND NUMBER IS LESS THAN1740 Rem FIRST NUMBER, DO NOT OUTPUT1745 Rem THE SECOND NUMBER.1750 Rem INPUT = VLA1755 Rem INPUT = VLB1760 Rem1765 Ha$=Hex$(Vla)1770 Hb$=Hex$(Vlb)1775 If (Vlb>Vla):Rem OUTPUT BOTH1780 Print #1; Using "/$!! /- /$!! &&& /- &&& ",Ha$(3,4),Hb$(3,4),Vla,Vlb;1785 Else :Rem OUTPUT ONLY THE FIRST1790 Print #1; Using "/$!! &&& ",Ha$(3,4),Vla;1795 Endif1800 Return1805 Rem1810 Rem DOMODIFIERS1815 Rem OUTPUT TEXT OF MODIFIERS IF SET1820 Rem INPUT = INSMOD INSTRUCTION MODIFIERS1825 Rem INPUT = DLINS INSTRUCTION1830 If (Insmod&$80) Then ? #1;" + DLI";1835 If (Dlins>1):Rem REGULAR GRAPHICS1840 If (Insmod&$40) Then ? #1;" + LMS";:Dladr=3:Rem THIS HAS TWO TRAILER BYTES TO PARTIALLY IGNORE1845 If (Insmod&$20) Then ? #1;" + VSCROLL";1850 If (Insmod&$10) Then ? #1;" + HSCROLL";1855 Endif1860 Return1865 Rem1870 Rem HOPE FOR CLEANLINESS.1875 Rem TRAP ERROR AND CLOSE FILE.1880 Poke 82,0:Poke 710,0:Graphics 01885 ? "Trap Error ";Err(0);" at line ";Err(1)1890 List Err(1)1895 Trap 01900 Close #11905 End
Below in tar and zip file formats is the source program, and the program's output for all the regular Atari OS text and graphics modes (rename .tar.gz.zip to .tar.gz):
Source code:
EXAMDL.tar.gz.zip
EXAMDL.zip
Display List Dumps:
DLDUMPS.tar.gz.zip
DLDUMPS.zip
-------------------------------------------------------------------------------------------
1 Corinthians 3:19 For the wisdom of this world is foolishness in God's sight. As it is written: "He catches the wise in their craftiness";
-
Latest Entry
Battle Pong WIP
I've been trying to program a home brew for a while now. Here is a brief summary of where I am at this point.
Here is a picture of my previous attempt at the point I gave up. The program became too disorganized and there was too much useless stuff that confused things further.
Then I re-started with a more simple program that was much easier to keep track of. Here I'm using the same data to display both players and some playfield.
Then I split the screen up into 5 bands. I'll use one for the score, two for the playfield top and bottom edges, one for the main playfield and one for a special area of the playfield.
Here is the current version
- Read more...
- 0 comments
-
- 10
entries - 1
comment - 13442
views
Recent Entries
Latest Entry
Log
LiveJournal won't finish loading on the cell data connection, and my pattern has always been to blog in out of the way places (Advogato, whose admins gave me a cookie I saved in a text file when I lost my login info, use.perl.org, ...).
I'm rolling in to Davis, CA, where a bunch of exceedingly tiny houses in a row are connected via some duct-like overhanging facade in the front. They look like they might have a living room with a bed nook jutting out. Leaving, there are electric third rail warning lines.
I followed the shore line down to Amtrak Emeryville after essentially riding to Rebecca's boathouse, then wound up on the wrong side of the tracks, fobbling down a few blocks trying to get around a mysterious one way street, then a street that only dumps into a shopping complex parking garage, then heads towards freeway interchange before turning around and spotting a ped overpass on the GPS. It has stairs and elevators, and the elevator on the far side dropped me right where I'd be boarding after removing protrusions from the bicycle. The Richmond station is another case of popping out of an elevator and finding yourself on the train platform.
As a kid, I at some point became aware of bicycle of bicycles without kickstands. Maybe it was in the small-town Schwinn dealer. I don't know. It seemed alien and impragmatic even though my cousins and I would often pick our bikes up from the ground crashing them, or perhaps because of that. The bike comes up off of the ground because you wiped out, and picking it back up is associated with doing a quick mental injury check.
The Amtrak baggage dude who was being super-helpful and asked me if I had ever done that before -- package a bike into an Amtrak bike box. "No, but I have packed it into my own bag in the past when riding Amtrak". He told me yeah, they started getting serious about the bike boxes after someone's self packed bike popped a kickstand out while being handled, and the kickstand lodged in the handler's shoulder. Ouch.
There's a jackrabbit running along the tracks. We're stopped again, this time in Sacramento. There's a jackrabbit running along the tracks.
There's something about getting on a train, or getting ready for a long trip. You have to make peace with where you're leaving from. I read an article once a long time ago that attempted to to answer the question of why you forget what you were doing when you go into another room to do something (or, alternatively, why sometimes old people will walk into the supermarket and the step dead as soon as they've planted foot inside). Temporary changes in context help break life up into chapter.
- Read more...
- 0 comments
- 10
-
- 16
entries - 181
comments - 35541
views
Recent Entries
Finally completed!
This idea started when I acquired a 5" LCD panel about a year ago, and I thought about making a mini arcade machine around it. I figured 1/4" scale, because originally they used 19" monitors, so 20" (I rounded up) divided by 5" = 4. I then decided to start with a mini upright pacman, and would like to do others as well (i.e. Asteroids, Defender, Galaga, etc.) Sort of like a 'mini arcade' for people like me who don't have the room for full size cabinets.
First this I have to say, is that this would not have been possible without John from Boulder Arcade Factory. He was helpful, willing to try something new (he usually sells full size cabinet recreations... I made a Cabaret version with one of his cabinets here), and just a nice person all around.
John made the scaled-down cabinet out of MDF, and I took it from there. The cabinet was perfect, and he paid attention to every detail.
Unfortunately, the side art I had printed last year came up a little short (about 1/2 inch), so I painted the bottom. I must have mis-measured last year when I was trying to build it myself.
Other than that, I tried to follow the exact way the full size cabinet is made. I ended up 3-D printing:
- The marquee retainers
- The red joystick ball
- The Control Panel itself
- The Coin Door
- The speaker grill
AA user 'spawnshop' desgined the coin door, and printed the first one... which I subsequently ruined
since then, I purchased my own 3-D printer, and was able to print another two of them, using his design. Thanks spawnshop! I found a small joystick on the net and used that as you can see in the pictures.
I pulled off the keycap, and printed the Red ball as noted above.
I also used Orange magic marker for the ‘t-molding’, and black marker for the inside.
Still need to figure out a 'non-permanent' way to attach the monitor bezel (which has the LCD panel attached to it), as well as the Control Panel.
I used a Raspberry Pi for the innards, and made it boot directly into Pac-Man only.
Thanks, guys!
Bob
- 16
-
- 4
entries - 4
comments - 4662
views
Recent Entries
Latest Entry
E3 Announcements! Its Happening!
Oldschool PS1 fans prayers have been answered! The gaming gods of playstation have handed down blessings fourfold this day at E3! Sony announced at their press conference that they and Activision would be remaking Crash 1, 2, 3 for the PS4! On top of that, Crash is bringing the Bandicoot to Skylanders! Thats it! Im getting a PS4!
- 4
-
Latest Entry
Do you know this system?
Anyone know the year this was made? Nutting Associates warranty says model 180-LA and serial 36101 -
- 42
entries - 46
comments - 127894
views
Recent Entries
Latest Entry
Marty refuses to leave.
Well, it looks like I won't be parting with the FM TOWNS Marty after all. I officially sold it (i.e., received payment for it) last Tuesday. I streamed it Thursday night afterwards and then went to record last-minute game footage Friday night before shipping it out, only to find that the discs refused to spin. I dug into the unit and could only surmise it being an issue with the laser (the switch that makes the drive spin seems to function properly). I moved it a little and it started working again, but then 30 minutes later the discs stopped spinning once more, to which I tweaked it again and it started working a second time. So, the Marty is too unreliable to sell and I just provided a refund. I don't exactly have a paperweight on my hands as it seems like it's functioning now, but it is going to need some TLC in the future and is not in a sellable state. Even if I do get it working 100%, I'm not sure if I will sell it again. Perfect timing on this current failure though, it's almost as if the system doesn't want to leave my collection, haha. Anyway, if anyone knows where you source replacement drive lenses for the Marty, let me know.
- 42
-
Latest Entry
Midwest Gaming Classic
Had a great weekend out at the Midwest Gaming Classic. Got a lot of praise for the Lego NES consoles, and there were a number of people interested in buying one of them. The highlights of the event for me were seeing Ben Heck's giant Game Boy and getting to chat with him for a bit, and seeing the band Mechanical Life Vein play a jazz version of the Metroid music while a guy in front did a speedrun of it. Also was cool to see the Nintendo Playstation prototype, and had a huge laugh at the Coleco Chameleon out in the vendor hall.
While I did have way too much fun and excitement over the weekend, its nice to be back at home with the family. Also nice that things will be slowing down for me and getting back to normal.
- Read more...
- 0 comments
-
Latest Entry
5200 spare 4013 IC?
Anybody have a spare 4013 IC I could use for some upcoming 5200 surgery? Yeah, I could get like five of 'em for $1.50 shipped from China, but I don't need five... and if one of you fine folks has one laying in the bottom of a drawer...
-
- 2
entries - 0
comments - 2788
views
Recent Entries
Latest Entry
From: TL866CS MiniPro Eprommer
Absolutely great!!! I now have an English help file!!
Source: TL866CS MiniPro Eprommer
I downloaded the file but it only translated the left side - when clicking on any items there - nothing displayed on right - what is wrong?- Read more...
- 0 comments
- 2
-
- 3
entries - 12
comments - 4741
views
Recent Entries
Latest Entry
Long Overdue Art Update!
I had some computer problems (my windows XP machine died), and now I'm working on a cheap laptop, while I get things sorted out.
Here's the last mock-up I had worked on, for "Cat Quest 2600". Dark Caves, lit by a lantern item.
Enemies would be invisible in caves, when the player does not have have the lantern.
Recently, I've been working on a collaboration with a fellow porn artist, on a hentai parody of Hydlide.
The game is titled "Transamnia", after Global Transient Amnesia.
The game's plot follows a hermaphrodite heroine Jizzabelle, on her quest to fuck, or be fucked, while facing off against the forces of a mysterious entity known as "DARK PHALLUS"
(Insert adult-themed cover-art here, complete with phallic imagery. Which I will NOT post, here.)
The game is NROM-restricted, and makes use of organic tiling, for a more convincing world.
There is time travel across 5 time periods, all of which are affected by Jizzabelle's actions in the past.
(For example, Jizzabelle can impregnate NPCs in the past, increasing the future's population.)
Here's a preview of a more recent mock-up. Beware of fish nipples.
- Read more...
- 0 comments
- 3
-
Latest Entry
galaxian 2600
man when i picked this game up from the fleamarket i was super excited. i mean i was excited like Hillery Clinton getting out of lying about landing under sniper fire, or lying about email security. I was excited! I had been playing galaga 7800 and enjoying it, but my heart always beckoned back that 2600 time. Just like Doc brown took me back in time, I found that copy of galaxian! I jetted back home to my own time and slapped it in! Instantly remembering the sounds, graphics, control's. It was wonderful. My wife recently picked it up and started playing it. She loves it (and is playing it right this very second). The game looks great. The game plays great. The game is just that. It's just great! Thanks for taking the time to read what I thought of it. God bless
-
Latest Entry
Retro Games - Paintball Zones
Saw this infographic and thought I'd share.
Remember Nascar on the Atari? Looks a bit repetitive on this vid!
-
- 92
entries - 70
comments - 87996
views
Recent Entries
Latest Entry
RockCutter is now set at 128KB Megacart
I started another project after I failed to convert Rockcutter a Megacart format. I soon figured out that if --codeseg bank1 is in that command line, then it would compile the code and const segment in 1 bank. SDCC -? help got me a list of switches to tell me what each switch does. So I found --codeseg and tried it out. Sure enough it compiled both const and code in 1 bank. I used cvmkcart.exe to put the segment together and sure enough it works(once I figured out which bank is the right one.)
So I decided to try making Rockcutter to Megacart again that I know --codeseg is needed. I first made a 80KB ROM since I already made 4 banks of graphic and code, but it failed to work. So I already experienced with 128KB, so why not go for that size. Sure enough I was saw KIWI on my logo screen, which the font was taken from the BIOS. No graphic was loaded since I was at the wrong bank. So I fudge around with it until the game was running perfectly. So now it work like my original 32KB version. I can now add more stuff to it. Music is one of the feature I want to add to this game. Better titlescreen for sure and better ending screen. Even a story screen, and a tutorial level for those who don't want to read the manual first. Maybe add more tile graphic to the levels.
I really need to get on making that manual. And hopefully the game will be release in Summer 2016.- Read more...
- 0 comments
- 92
-
Latest Entry
John Lester's Coleco Chameleon Thoughs Transcribed
For those who don't wish to watch the Gamester81 coleco chameleon thoughts video, the following is a rough transcription of John Lester's dialog from it. I will not go as far as to say it is a perfect exact word-for-word transcription of it but it is the best and fastest I could do. It is quite long:
Guys whats going on? before I start with the cc because i have a lot to say uh about this, just a quick disclaimer. I know it sounds cheesey but uh I have a lot of people come up to saying that they watch my show with their kids and they enjoy. Being a parent myself I respect that, I think its awesome. So, This may not be the best video for your kids to watch honestly, uh I'm pretty pissed. (laughs) and uh I did and uh honestly I'm not one for confrontation. Last thing I want to pride myself on having a lot of friends and no enemies and uh know where I'm at right now (laughs). And I'm not here to change anyone's opinions. k? Opionons are like assholes we all have an opion i respect others opinions, I don't expect everyone to agree with my opinion. I don't expect people to watch this video and people to say wow john you were absolutely correct and wow I changed my opinion. I don't expect people to be that easily swayed. I'm not here to defend the Chameleon either, cause, lets be honest, just be honest. it's beyond defending at this point ok? uhm, but I simply here to defend my reputation, defend my, my uh integrity cause its been taken a jab at uh recently and that kind of fucking pisses me off to be honest, to be completely honest with you. So I've been part of the gaming community since 2008 uh I've made a lot of friends. The gaming community I'll be honest with you guys, means the world to me. You guys not to sound tacky are like family to me. You guys are awesome, everything about how you feel about the show, how you feel about me as a person, means a lot. You can call me ugly, you can call me stupid, whatever I've got thick skin but when people start attacking my integrity I take that very very seriously. Uh and recently a video came and I'll talk about it later in the video that uh may not, may indirectly call me out and put me kind of in the corner so I feel like I have to do this video. Because I was going to initially going to stay quiet and distance myself because I don't want to add fuel to the fire so to speak. I'm not that kind of guy.
So, for those who don't know I am co-owner of a company called collectorvision games. We produce new games for old consoles. ok? So, for example, uhm we you know, we have games coming out for modern consoles, like you know we have games coming out for like ya know, xbox, wii u, ps4, steam, all that good stuff, right? And we also have games coming out for the classic consoles, so anywhere from Atari 2600 believe it or not or Commodore 64 to, to dreamcast it just kind of depends so everything in between, ok. um so the only reason I mention this cause I'm not trying to promote my business to you guys but its relevant to my story I'm going to tell you to my involvement with the Chameleon. About a year a go Mike reached out to me and said John, I'm working on a project its called RETRO VGS Video game system. um I'd like you to be part of it I understand your company works on games. I've known Mike for years, I trust the guy. That's how when you have friends you tend to trust your friends, obviously. So I had no reason to not trust him. You know, agreed, and basically the agreement was, I was told the Retro VGS would run off a FPGA board and basically you take the ROMs and would be able to read the ROMs. So, we wouldn't spend any extra time or money on it. We were already working on two super nintendo, tiny knight and sydney hunter and the caverns of death. So, the agreement was just give him the ROM and he'd handle the manufacturing side of things, we would get a percentage of each game cart and we'd have the pack in game as well. So, for every game system sold we'd get x percent. I'm not going to dive into what percentage that was because, A. it's none of your business and B its not really relevant to the story. But just know that was the kind of agreement. Retro VGS failed, obviously, it was way over expensive. It was just Frankenstein and a whole bunch of things and you know, played Unity and it was really cool but it was just too much. $400 was way too much for a system out of the get-go and no one wants to pay that. There was no prototype ever issued, And during this whole time people were just going on Mike and which caught me off guard because he's been involved in other projects like RETRO Magazine, keep in mind, I still enjoy. Gamegavel.com which is like an ebay auction site for gamers, been around for years. He's done podcasts, retrogaming roundup, for years and people enjoy that. So, theres nothing to me that really told me that spoke out like wow, I should question this guy's motive because he clearly has had a good track record up until this point ok. so ok cool, so the thing obviously fails and during this time I reached out to Mike. Mike let's interview you, get you on my show, talk about your shop. I got a lot of slack for that cause I guess at one point I said, What do you want to address to the haters at Atari AtariAge? Right, So, that was wrong and ignorant of me and I apologize. I know that now. So, I took the video down, A cause the system was no longer, you know, going to be, so why even have a video on it? It's my channel, I can take a videos down and and and also I felt bad about what I said. I apologized to the community, I really do feel bad about what I said.
So, people were upset with me that I took that video down. It's like oh my god, I'm guilty of taking my own video down. Shame on me. Shame on me. Guys, its a horrible, terrible thing to take a video down, fuck. So, Uhm, so so ok so fast forward uh campaign retro vgs is done, mike reached out to me again. Same kind of deal. We weren't going to Tiny Knight cause Tiny Knight wouldn't be ready for Christmas this year to be honest with you. So you know, Sydney hunter, we talk about as a pack in game. He told me other things, other projects going on. Really good things about retailers possibly carrying the system, among other things. Right, again, none of my business to talk about, I don't want to dive into details, these were all discussed behind closed doors, but just know that, you know, there is reasons and intensives for us to do that. Again, I had nothing to do with the hardware side of things or the decisions behind it. We fast forward to the toy fair, they show the back of the console. Has the cables out like the super nintendo, ac adapter like the super nintendo, uh controllers like super nintendo controllers, it doesn't look good for uh you know when I saw this video, when I saw this picture rather, it's the first time I saw it as well. So, It caught me off guard as well, so people assume that like I was somehow involved in this shit. From the beginning and have some stake in the company, ya know, I guess I do from the point of game sales and the percentage I'd make from games sales but I'm not a part of any decisions. I'm thinking to myself what the fuck, what is all this shit? Now I'm like you guys this is suspect, it looks like a super nintendo inside a jaguar shell. You know but the thing is, I've talked to several hardware guys and here's the thing about prototypes and I don't know if you guys know this or not, by all means I am not a hardware guy, ok. So, I might be completely off base here, but from my understanding is, there are several different type's of prototypes in the stage of prototypes. So, its like you just have a prototype and the next one is the finished product, it's just not how it works. There can be five, ten sometimes more prototypes before you get the final and usually the final prototype looks a lot different than the first prototype or even the tenth prototype. That's the reason why you don't see prototypes for nintendo, sony, microsoft, excreta, you just don't see them publicly, they keep them hidden for a reason. And during the early prototyping stage, they actually, it's not uncommon to take parts from the other boards and stuff and other products to kind of hodgepodge them together and see how it works. That could have very much been the case here, again, I'm not defending the Chameleon, I'm just saying this could have been the case, it could have been the explanation as far as why there was parts of a super nintendo. Mike could have opened it up and done a video, he didn't. So again, Suspect. Right? And I totally agree with you guys again on that.
Now, we're gonna fast forward a couple more week or so ago, a couple weeks and this is the day before the Kickstarter was supposed to launch. Friday it was supposed to launch and this was Thursday. At this point I still don't know, I still have no contract, I have not signed, I still have not signed a nondisclosure agreement. I have not signed an agreement for Sydney Hunter, which is the only game we've agreed to port over to Chameleon and uh, I still haven't had the agreement in hand. And so, I guess, you know, on paper we are not linked to the Chameleon at all. I contact Mike, I'm like what's the deal with you know, cut to money before, I'm like dude what's the deal with this? He's like, I'll give it to ya. I never got it. He's busy. I'm like, whatever. So, finally, I get, I never get the agreement but the day, I find out that there's something that's changed, we had a new agreement that he told me about. Again, I don't want to tell, this was talked about behind closed doors, I'm sorry guys. But just out of respect of our conversation and my word. But, I will say this, something had changed, somewhere in that agreement and my understanding between talking to Mike and it pissed me off. It frankly did and I said you know what, I'm done, I wash my hands of it, I'm out. So, literally the night before the kickstarter was supposed to launch, collectorvision games pulled out. Like, we are done and Mike called me back cause he's obviously flustered because Kickstarter was supposed to launch, you know, tomorrow or the next day, and he has no like publisher of one of his launch games is out, and all the videos he has of Sydney Hunter and all that good stuff so he's basically screwed. And you know he's like, Oh John, I'm a stooge, lets push it back Kickstarter, we'll figure it all out. That's probably one of the reasons the Kickstater got pushed back. So, the whole thing has been miss managed from the beginning. Guys, has Mike fucked up? Yes. Did he make mistakes along the way? Yes. But, here's the thing, Who hasn't fucked up? Who hasn't made mistakes?
If you are perfect, if you have never fucked up in your life, if you have never made mistakes, if you've done everything perfect, I would really like to shake your hand because you're probably mother fucking jesus. You probably are. So, So really we need to get off our high horse, we need to quit pointing fingers, we need to stop assuming that everything is a conspiracy. When really, there could be answers to stuff and when you're looking for facts, guys, go to the source. And that's what I tried to do with the retro vgs. Or I tried to do, right. The reason I'm doing this video is and it's really because I've been called out, indirectly called out is by Pat. Let me say one thing very very clear, Pat the NES Punk is a friend of mine. We've known each other for years. 5-6 years ago we were at PAX, I had a great time hanging out with him. I hung out with the AVGN james and Game Chasers. It was a great time. We had a fantastic time. It was actually like one of my highlights in my youtube career for lack of a better words. If that's what you want to call it. I still have a day job, its not much of a career for me. Regardless, it was definitely a highlight for me, just say that. So, it was a highlight for me, Pat is a super nice guy. As of recently, as of last year. I flew Pat, paid for his flight to come out to Phoenix, to come out to my gaming expo that I do, called the Game On Expo. Paid for his flight, paid for his hotel, gave him a free booth to sell his merchandise, free table and uh gave him a panel. It was a great time, hung out, had a few beers, whatever, we had a great time. As of last week I reached out to Pat to come back with Ian this time for this year, later on. I'd love to have him come back. The invitations always open for Pat to come in and be part of Game On Expo.
So, no quarrel with pat whatsoever. But, I do have issues with his recent video about the Chameleon. And in this video the most recent video, its like a seven minute video. He's talking about the board, oh I forgot the mention, of course, one of the most important things right. Kickstarter got posponed and they posted a picture, picture of the prototype or the board, the capture card board. Again, caught me off guard. Looks like a duck, quacks like a duck, right. So that, completely caught me off guard, I was like what the fuck is this. Just like everyone else, okay? So, back to Pat. He talks about this board, he brings it up and he's like, and I'm of course para-phrasing, but he's like, you know, fool me once shame on me, fool me twice shame on you, full me three times fuck off. So he's like, right, in the middle of this video he's like, fuck this is bullshit fuck, you know and he's all getting worked up, and I'm thinking to myself through this whole video, dude, I wanna give this guy a hug, because it's like, I realize that bigger shit is going on than. I'm sorry, I don't mean to down play the whole Coleco Chameleon but lets face it guys, no money was taken. Even with the Retro VGS No one lost any money, I mean, it's like, people are like vilifying uh the situation, like its the worst fucking thing. Dude, ISIS is blowing people up everywhere in the world, kids are starving in the streets, there's you know, he's talking in this video like it's world war three. I'm like what the fuck? and he's like, fuck this is fucking bullshit and I'm ya know he's rallying the troops and in between the video and in the middle of it he's calling out websites that are posting the press releases for the community. Come on dude, you have a website, you know how this works. When you get a press release, it's not your job, you are no accountable for the action of the company. I mean come on, that's bullshit right? Then he calls out RETRO Magazine which again I guess he forgot to mention is that Pat at one time at the start of RETRO Magazine, he was a key contributor to the magazine. He worked closely with Mike, he was like on the team, I duno if he was paid or what that's none of my business but he was part of the RETRO Magazine. So, yeah, he worked with Mike before. So he knows mike pretty well, so he knows mike. And then in the middle of the video he has the audacity to say that, anyone involved in this project should come out to the public and apologize. It's bullshit cause you are, you are, you are part of the project and you are part of the problem. Cause we were fucking supposed to know that shit was going to happen, right? And to say that, it's like this guys, like Sony, lets say the PS4 gets hacked and all of a sudden everyone's PS4 dies and crashes, alright. It's like me going to Naughty Dog and saying Naughty Dog, shame on you for publishing games for this PS4, explain yourself, come out and apologize. I mean that's fucking, it makes no sense to me whatsoever and the logic and he didn't call me out by name. He didn't say Gamester81 or say Collectorvision games but he didn't exclude us either. And then you know people have been on twitter and stuff and facebook, they've been asking me would you clarify your stance? And silence speaks louder than words sometimes. Now I know where he stands on this. So, according to Pat, we are all guilty by association. Because when he worked with RETRO Magazine, it was cool and everything worked out well. It didn't. And when I worked with Retro VGS and the Chameleon and shit hits the storm. And I don't wanna bring up the past cause, I'm not about that. But, if I recall Pat was a part of a Kickstarter that was kind of controversial and no one ever asked him to apologize and no one gave him shit for it. Uhm so, I don't know why all of a sudden I get the fucking Imp. And Pat when you make these kind of things, you are in a position of great power, because you have a lot larger audience even than I do and a lot of other people. And you say these shit and you know people listen to you like its the fucking gospel sometimes man. And I'm like Dude, okay so, I don't know whatever happened to people phoning home but please do your homework and realize that's what you're doing is basing your opinions on these guys showing pictures and all of a sudden these pictures are facts. I has ever dawned on me that there might be a minute chance, a very minute chance that maybe there's explanations for somethings that you see pictures wise, maybe there's an explanation for things has anyone ever dawn, did he ever dawn that he ever actually reach out to mike and ask mike. If he was so concerned about the Retro VGS and the Coleco Chameleon and how the shit was supposed to be wouldn't you think that he would actually go to the source and the find out facts, opposed to like basing his argument based on pictures. And guys, don't get me wrong, I agree that the pictures they look bad and that I'm on board, I agree with what you guys are saying. I'm not saying Mike, I'm not saying that he was right in any of this, he fucked up. But, we need to get off the fucking iris and I'm sorry to say, I'm sorry but who made Pat the fucking Judge of the internet? Who made followers the fucking Jury during this whole shit? Like why should I have to go out and apologize for trying to get my name out there to the masses? What's fucking wrong with that? I'm sorry but this kind of pisses me off a little bit. Ya know? So uhm, you know, you can question, when you start questioning my integrity which you are and my respect and my motivations to get involved with projects, you're assuming that I'm in it for the ill-will and that's just bullshit, so. Yes, I'm sorry if you feel that I have cause ill-will, I'm sorry if you feel I've done shit wrong, I'm sorry that you feel that way. But, I'm not going to apologize for fucking trying to do the best for my company. Ya know, and there's never a time and I do apologize to my company, my collages at Collectorvision games, a number of times they said, hey let's get out and I was Calm, I'm guilty of being ignorant, I'm guilty of being gullible, I'm guilty of being naive, I'm guilty of being many things. So, I am certainly no fault. I'm sorry, I didn't mean that, I'm certainly at fault in some of this as far as us being involved until the very last day, anyway. But I had no idea, this is news to me. So, where do I stand on the Chameleon? I am disappointed, I uh thought the thought of it was cool.
I thought, I think Mike is a guy who intentions I think were sincere. You know, I'm not calling him a liar or assuming he is a liar and deceitful. Look, here's the deal guys, he owns RETRO Magazine, he owns the Gamegavel.com, other business entities, why would he logically? Just think about this, why would he logically want to fuck people over, intentionally? And try to lie and deceive people if he has all these. Would it not effect, it is effecting these other areas, I'm sure. Also, look at his website, he's got six other guys, seven other guys on his team. Look at the history the resume and all the gaming community and they have a really good strong record up to this point. They're legit guys, so, what are the odds of all seven of these guys getting together and saying, how can we fuck people over? how can we do this shit? I don't know. Let's do it. I don't know what are the odds of that? Now, is it possible that Mike is doing this shit behind their back? I duno maybe, that's quite possible. But the odds of all seven of them rolling together and saying, hmm, lets try to scam people. I just don't think that makes sense. If, my point is, several take aways from this video guys. A. Don't. Form your own opinion, please. Form your opinion, don't take shit you hear on one video that's gospel. Uh, Two, there are always two sides of the story. Every story has two sides. I feel like, in this situation a lot of people are siding with the side that they are, you know, that people want to, they want drama, right? And then, all in the video Pat, in the very end he mention's his book but if you look at the video, his video use. It's the Chameleon shit that's getting a lot of views and I don't blame the guy. We look at, we wanna get views and subscribers to get money but you do that shit to get back at people, you gotta realize when you're talking, when you're bringing something up, you are mauling on people, you effecting people, like myself, and when you start doing that shit and you start effecting other people, that's kind of fucked up, in my book. Because you, you're taking a topic, you're not really thinking through it, looking at both sides, you're looking at basing your argument on pictures, basing your argument on that, you haven't gone to the source, you haven't even reached out. No one reached out to me, to ask me what my opinion, my involvement with Collectorvision Games are. Uhm, you know, I would have been happy to talk to people about it. No ones ever fucking reached out to me, so you know I'm kind of thinking, you might have done this shit just for the views, I don't know. And then he's like, I'm gonna take the gloves off, I'm gonna talk next week. And I'm thinking to myself, gloves off what? You're going to beat a dead horse. Let's face it, the horse is dead ok. Why are we gonna beat someone already down? You're gonna kick someone while they're down, ok good. Good for you. You wanna be that, that's your prerogative, ok go for it. I really think that maybe, uh, society in general maybe, for some fucked up way, we like to beat people while they're down. Maybe it helps us In some fucked up way we feel better about ourselves? Because we're kicking someone while they're down, I don't know. So, my take is yes, mike fucked up. Uh, it's an ugly situation. I'm really fucking pissed because it has effected my company, the way people are associating us with the Chameleon its far from the truth. And I feel bad. I feel bad for Mike, I feel bad for the people involved, I think uh, but I'm not gonna sit here on a high horse and say, you fucking shoulda done this, you fucking shoulda done that and you are fucking wrong. That's that's not who I am. So, take it for what it is, that's my opinion.
You know, again, I don't wanna fight with Pat, that's the last thing I want. But, the last thing I want is for you to go to his channel and unsubscribe or start a war, Team Gamester vs Team Pat. I'll tell ya right now he'll prolly win because I'm not going to respond much. I'm washing my hands of this. I'm working on other shit. I've got a Pier Solar Dreamcast review. I'm doing a RetroFreak system review I'm working on. So I'm already moving on from this shit, I've learned from it. Uh, I'm moving on. I'm growing from it. Let's all move on together, there's no sense in just keeping in doing a video for video on it, getting those views, getting those subscribers. If that's what you wanna do that's your prerogative, go for it. But I am done with this. Uh, you know, I respect Pat, I respect Ian. Again, I hope they come down to Arizona for Game On Expo. Uh, you know, I have nothing against them personally, This is really bullshit when they start calling people out and people start listening like the fucking gospel, they're the fucking see all do all judge of the internet and I just don't get that. That's just kinda pisses me off. Thank you for hearing me rant, it's good to rant a little bit. Cool off, I appreciate you guys, the community means the world to me. Let's just move forward. As far as Collectorvision games goes, we are working on other games, hasn't really effected us as far as production. We are working on our games, we are moving on from this and I hope you guys do too. We'll see you guys soon, take care and game on.- Read more...
- 0 comments
-
Latest Entry
This is embarrassing xD
After all this time I finally discovered that object oriented programming can be used in batari Basic xD, *facepalm* I know that is embarrassing the time it took me to find out that you can Dim anything and rename it xD, I'm currently working on a interesting game idea, maybe not so original but I think it's clever, once I have the first playable I'll upload it for anyone interested in playing it, I'm looking forward for testers
.- Read more...
- 0 comments
-
- 38
entries - 31
comments - 20749
views
Recent Entries
Latest Entry
Thunder...Thunder...Thundercats...Hooooo!
Just another one of those childhood images that haunts my brain! The Thundercats logo
This is another one of those shows I wasn't really obsessed over or anything but enjoyed. I never went as far as collecting any of it, I don't think I even owned any of the toys back in the 80's but I do remember the TV show quite well and can instantly zap myself back in time by hearing the intro! In tribute to this iconic cartoon of the 80's I made a logo for my garage!
This was a fun one because I was able to use a new "tracing" feature I learned in autocad, basically instead of drawing it completely free hand I was able to trace around a picture of the logo I dropped right into the autocad frame, turned out to be a very useful feature for me and was able to replicate the logo rather well
Nothing fancy on the materials, just a stock red and black which is a dead on match to the cartoon....
THUNDERCATS......HOOOOOOOOO!!!!!!!!!!
- 38
-
- 20
entries - 16
comments - 8643
views
Recent Entries
Latest Entry
Atari Moria native 40-column version
I've started on the conversion to native 40 column mode.
Memory configuration was the first thing I had to tackle. I was able to carve up the data structures that are currently being held in VBXE memory and banked into $4000-9FFF, to fit in the extended banking window of $4000-7FFF instead. I was able to keep all monsters and items, and keep the total size of the map the same as in the VBXE version, although with a slightly different horizontal and vertical size (88x66 in the 40-column version, 22x22 visible on screen, versus 132x44 in the 80-column version, 66x22 visible on screen.) The game will still require an Atarimax 8Mb flashcart, and an XL/XE computer since I'm using RAM under the OS.
There are still some major issues to work out, mainly regarding trying to squeeze onto the screen the information that Moria normally presents in 80-columns. I'm going to have to make decisions around some things, and I hope to keep the changes to a minimum.
I'm currently working on getting everything working correctly with the new screen sizes and memory layout. Some functions will need to be rewritten, and some object names may need to be shortened, for instance the "Holy Book of Prayers [beginner's Handbook]" is over 40 characters, and there are a few other examples like that. I hope to have a demo/beta version soon!
This game was never designed to be run in 40-columns, that's for sure! But then again, it was never designed to run on a 6502 with 64k either.
- 20
-
- 5
entries - 9
comments - 7187
views
Recent Entries
Latest Entry
TI 99/4A Memory Map
TI-99/4A Memory Map
>0000 Console Rom;
Interrupt vectors, XOP vectors
GPL Interpreter, Floating
POINT routines, XMLINK vectors,
>1FFF Low-level cassette DSR etc.
>2000 Low Memory Expansion Ram;
Varies according to the loader
used (Assembly). Generally
>3FFF not used by XBASIC programs.
>4000 DSR ROM;
Device service routines.
Determined by CRU bit setting
>5FFF Disk Controller, RS232 etc.
>6000 Cartridge Port (ROM & MINI MEM)
12k of XBASIC ROM. Upper 4k
@ >7000 - >7FFF is flipped to page in another 4k for a
>7FFF total of 12k.
>8000 RAM Memory Mapped Devices - VDP,GROM, SOUND, SPEECH.
>8000 Duplication of scratch pad RAM at >8300 - >83FF
>8100 Dup. as above
>8200 again
>8300 Scratch Pad RAM
>8400 Sound Chip
>8800 VDP READ DATA
>8802 VDP STATUS
>8BFF
>8C00 VDP WRITE DATA
>8C02 VDP READ/WRITE ADDRESS
>8FFF
>9000 SPEECH READ
>93FF
>9400 SPEECH WRITE
>97FF
>9800 GRON/GRAM READ DATA
>9802 GROM/GRAM READ ADDRESS
>9BFF
>9C00 GROM/GRAM WRITE DATA
>9C02 GROM/GRAM WRITE ADDRESS
>9FFF
>A000 HIGH MEMORY EXP RAM XBASIC high memory usage, Free space end pointed to by CPU RAM PAD address >8366
Numeric Values
Line Number Table
XBASIC Program Space >FFFF for a total of 24k bytes.
Additional Memory Space not in the CPU address space;
VDP RAM >0000 - >3FFF 16k bytes.
This is the console RAM space, and is separate from the rest of the CPU memory. Without memory expansion, XBASIC and BASIC programs reside here (BASIC does not use expansion memory.) (Assembly language does not use this area.)
BASIC does not use memory expansion at all. Only XBASIC, Assembly, FORTH etc. use it.
Chunks of memory are used by various peripherals as buffers, thus the amount indicated by CALL SIZE is right.
By using CALL FILES(1) followed by NEW, you can get back some, but disables the disk system. If you don't have it installed, but have mem exp. you will have more memory to use automatically.
Original Source as posted on July 8th 1984 by Gene Sampieri
The following is priceless as found in the below address:
http://www.unige.ch/medecine/nouspikel/ti99/tms9918a.htm#Registers
VDP memory
The videoprocessor has 16K of private RAM that it used to store the screen image, the character patterns and colors, and the sprite characteristics. Unless it is used in bit-map mode, only a small portion of this memory is effectively needed. The remaining is therefore available for use by the CPU. However all reading and writing operations must be carried on by the videoprocessor. The CPU passes the required address to the VDP as two bytes at address >8C02, and can then read bytes from >8800 or write bytes at >8C00. The VDP increments an internal pointer after each read/write operation. Contrarily to the GROMs, one cannot retrieve the value of this pointer from the VDP. Instead, address >8802 is used to read the VDP status register. This is definitely a slow way to access RAM, but it probably allowed to market the TI-99/4A at a much lower price, since RAM was fairly expensive in the 80s.
VDP registers
The first eight registers are used by the CPU to control the VDP. Very unfortunately, these are write-only registers, which means there is no way to determine the current display mode, unless it has been saved somewhere in RAM by the program that set it. Registers 0 and 1 contains control bits, registers 2 to 6 contains pointers to various tables in the VDP RAM and register 7 encodes 2 colors.
The VDP also contains a read-only status register that is uses to pass various information to the CPU.
VDP register 0
This register contains two control bits. All other bits must be zero. The register contains >00 after a reset.
Bit 6 (weight >02) selects a bitmap graphics mode when set to 1. VDP register 1 determines which bitmap mode is used.
Bit 7 (weight >01) enables external video input when set to 1.
VDP register 1
This register contains 7 control bits. All are set as 0 after a reset.
Bit 0 (weight >80) selects the memory size. For 4K of memory the bit is 0, for 16K it is 1.
Bit 1 (weight >40) enables the screen. When this bit is 0 the screen is blank.
Bit 2 (weight >20) enables interrupts. When this bit is 1, the VDP issues interrupt signals on the INT* pin each time it resumes refreshing the screen (vertical retrace signal).
Bit 3 (weight >10) selects text mode when set as 1. Bit 7 of register 0 can be set for bitmap text mode.
Bit 4 (weight >08) selects multicolor mode when set as 1. Bit 7 of register 0 can be set for bitmap multicolor mode.
If both bits 3 and 4 are 0, the display is in standard mode (or in bitmap mode, depending on register 0). Bits 3 and 4 should never be set together.
Bit 5 (weight >04) is reserved and should be 0.
Bit 6 (weight >02) selects the sprite size. When 0, sprites are 8x8 pixels. When 1, sprites are 16x16 pixels.
Bit 7 (weight >01) selects sprite magnification. When this bit is 1, each sprite pixel is replaced by a 2x2 pixels box.
VDP register 2
Defines the location of the screen image table. Only the last 4 bits are used, thus possible values for this register are >00 throught> 0F. The value is multiplied by >400 to find the location of the screen image table in the VDP memory. This table contains 1 byte for each character position on the screen (left to right, downwards), this byte contains the character number.
VDP register 3
Defines the location of the color table. Possible values are >00 through >FF and are multiplied by >40 to find the location of the color table. The table is not used in text mode, nor in multicolor mode.
In bitmap mode (i.e. when bit 6 in register 0 is set) the meaning of this register changes: bit 0 (weight >80) is the only one used to determine the address of the color table, which means the table has only two possible locations: >0000 or >2000. The remaining bits are used to define the table size, by the way of an address mask. This is done as follows: the righmost 7 bits are shifted left by 6 positions, filling the rightmost bits with 1s. The result will be a number between> 003F and >1FFF, which is ANDed with the address of a character in the table. As a result, the table can have any size between >40 and> 2000 bytes (however, note that the maximal usable size is >1800: 3 times >800 bytes).
VDP register 4
Defines the location of the character pattern table. Only the last 3 bits are used, thus possible values are >00 through >07. The value is multiplied by >800 to find the location of the character pattern table. Each entry in the table is eight bytes long and define the pattern of a character, in numeric order. Each byte in an entry defines one line of pixels in the character pattern: bits set as 1 result in foreground color pixels, bits set as 0 encode background color pixels.
In text mode (i.e. when bit 3 in register 1 is set) the last two bits of each byte are ignored since characters are only 6-pixel wide.
In bitmap mode (i.e. when bit 6 in register 0 is set) the structure of this register changes: bit 5 (weight >04) is the only one used to determine the address of the color table, which means the table has only two possible locations: >0000 or >2000. The two rightmost bits are used to determine the length of the table, by the way of an address mask. This is done by shifting them 11 positions to the left, filling the righmost bits with 1s. The result will be a number between >07FF and >1FFF that will be used as an address mask. At least, this is what happens in bitmap + text mode (i.e. when bit 3 of register 1 is set). In standard bitmap mode, the righmost bits are not necessarily 1: they are taken from VDP register 3, i.e. the address mask of the color table is used for both the color table and the pattern table addressing.
VDP register 5
Defines the location of the sprite attributes table. Only the last 7 bits are used, thus possible values are >00 through >7F. The value is multiplied by >80 to find the location of the sprite attributes table. Each entry in the table is four bytes long and defines a sprite position and color, in numerical order of sprites. See the chapter on sprites for a detailed description of this table.
VDP register 6
Defines the location of the sprite pattern table. Only the last 3 bits are used, thus possible values are >00 through >07. The value is multiplied by >800 to find the location of the sprite pattern table. Each entry in the table is eight bytes long and defines the pattern of a sprite, one byte per line. Bits that are set as 1 result on a pixel of the color defined for that sprite in the sprite attributes table, bits that are 0 result in a transparent pixel. If the large sprite size is selected (bit 6 in register 1 is set as 1) each entry is 32 bytes long and define a sprite as a set of 4 characters arranged as:
1 3
2 4
VDP register 7
The first nibble of this register defines the color of all characters in text mode. It is not used in the other modes.
The second nibble defines the background color wich is used for all characters in text mode. In all four modes it defines the color of the backdrop plane: this is the color of the screen outside the display area and the color that appears under transparents characters. When this color is set as transparent the external video image appears if it is enabled, black color appears otherwise.
Status register
The first 3 bits of this register are automatically reset as 0 when the register is read or when the VDP is reset. It ensues that the status register should only be read when an interrupt is pending, otherwise an interrupt could be missed.
Bit 0 (weight >80). This bit is set to 1 at the end of the raster scan of the last line of the display area (i.e. before drawing the bottom margin). If interrupts are enabled (by bit 2 in VDP register 1), the INT* pin is low when this bit is 1 and high when it's 0. This is why the status register should be read after each frame, in order to clear the interrupt and be ready to receive the interrupt at the end of the next frame. Also, if bit 2 in VR1 is cleared and set again while status bit 0 is set, an interrupt is issued immediately.
Bit 1 (weight >40) signals that there are 5 or more sprites on a given pixel row. Only the topmost four will be displayed.
Bit 1 (weight >20) is the coincidence bit. It is set when two sprites or more have at least one overlapping "on" pixel. This occurs even if the sprite color is transparent. Note that coincidence is checked only every 1/60th of second (1/50th of a second for the TMS9929A), thus if you change sprite positions during that time a coincidence could be missed.
Bits 3 to 7 contain the number of the 5th sprite on a pixel line, if any. This number is only meaningfull if bit 2 is set as 1 (else it may contain the number of the last displayed sprite, but no guaranty). If such a situation occurs more than once, the 5th sprite listed is the one closest to the top of the screen.
Summary of the VDP registers contents
Bit:
Weight: 0
> 80 1
> 40 2
> 20 3
> 10 4
> 08 5
> 04 6
> 02 7
> 01 VR0 0 0 0 0 0 0 Bitmap Ext vid VR1 16K Blank Int on Multic Text 0 Size 4 Mag 2x VR2 0 0 0 0 Screen image VR3
bitmap Color table Addr Address mask VR4
bitmap 0 0 0 0 0 Char pattern table 0 0 0 0 0 Addr Address mask VR5 0 Sprite attributs table VR6 0 0 0 0 0 Sprites pattern table VR7 Text color (in text mode) Backdrop color Status Int 5+ sp Coinc 5th sprite number
Video modes Standard mode (Graphic I)
This mode is selected by setting all mode bits as 0: bit 7 in register 0 and bits 3 and 4 in register 1. VR0: 0 VR1: 0 0
In this mode, the screen is divided into 24 rows of 32 characters. Each character is 8x8 pixels and has two colors: one for the "on" pixels (foreground color), one for the "off" pixels (background color). If a color is set as 0, the color of the backplane will be used (defined by register 7).
The screen image table is thus >300 bytes long (24x32=768). Each byte in the table contains the number of the character to display at the corresponding position on screen. This number is used to locate the character pattern in the pattern table and to look up its colors in the color table.
The color table is 32 bytes long. Each byte encodes the two colors for a group of 8 consecutive characters in numeric order (i.e. the first byte affects characters 0-7, the second characters 8-15, etc). In each byte, the first nibble encodes the foreground color, the second nibble the background color.
The character pattern table contains 256 entries, one per character in numeric order. Each entry is eight bytes long, each byte defines the pattern of one pixel row in the character: "1" bits set the pixel to the foreground color used for this character group, "0" bits set the pixel to the background color of this character group.--------| | 00000000 = >00| *** | 00111000 = >38| * * | 01000100 = >42| * * | 01000100 = >42| *** | 00111000 = >38| * | 00010000 = >10| *** | 00111000 = >38| * | 00010000 = >10 --------
The pattern table entry for the above character would be: >00 38 42 42 38 10 38 10
Sprites can be used in standard mode, see below.
Text mode
This mode is selected by setting bit 3 of VDP register 1 as 1. Bit 4 must be 0, as well as bit 7 of register 0. VR0: 0 VR1: 1 0
In this mode, the screen is devided into 24 rows of 40 characters. Each character is made of 8 rows of 6 pixels. All characters have the same two colors, defined by VDP register 7.
The screen image table is >3C0 bytes long (24x40=960).Each byte in the table contains the number of the character to display at the corresponding position on screen. This number is used to fetch the character pattern from the pattern table.
The color table is not used. The foreground color for each character is taken from the first nibble of VDP register 7, the background color is transparent, which lets the backdrop plane color appears. As the backdrop color is encoded by the second nibble of VDP register 7, one can consider that this register specifies both the foreground and background colors for each character.
The pattern table is organized just as in standard mode, except that the last two bits of each byte are ignored since characters are only 6-pixels wide in text mode.------| | 000000xx = >00| *** | 001110xx = >38| * *| 010001xx = >42| * *| 010001xx = >42| *** | 001110xx = >38| * | 000100xx = >10| *** | 001110xx = >38| * | 000100xx = >10 ------
Sprites are not available in text mode.
All this makes text mode the least memory-hungry mode: only a maximum of 3008 bytes (>0BC0) of VDP RAM is required in this mode. This can be further reduced by not using all 256 characters and/or by partly overlapping the tables.
Multicolor mode
This mode is selected by setting bit 4 of VDP register 1 as 1. Bit 3 must be 0, as well as bit 7 of register 0. VR0: 0 VR1: 0 1
In this mode, the screen is divided into 48 rows of 64 boxes. Each box is 4x4 pixel and can be independently assigned a color. The screen image table is still >300 bytes long, but each byte now represent a "character" made of 4 boxes. The boxes are arranged as:
0 1
2 3
The color of the boxes are defined in the character pattern table (!). Each entry in the table is 8 bytes long but only 2 bytes are used to define the colors of the 4 boxes that make up a character: >01 >23. To avoid wasting 6 bytes in each entries, the characters on 4 consecutive rows use the same entry, with an offset of 2 bytes:
characters on row 0, 4, 8, 12, 16 and 20 use bytes 0 and 1,
characters on row 1, 5, 9, 13, 17 and 21 used bytes 2 and 3,
characters on row 2, 6, 10, 14, 18 and 22 used bytes 4 and 5,
characters on rows 3, 7, 11, 15, 19 and 23 use bytes 6 and 7.
This reduces the size of this table to 1536 bytes (24 rows x 32 columns x 8 bytes).
The color table is not used in multicolor mode.
Sprites can be used in this mode.
To summarize, the screen organisation is the following:Column: 0 1 ... 31
Row 0: a b q r ... c d s tRow 1: e f u v g h w xRow 2: i j y z k l ...Row 3: m n o p
The corresponding screen image table could be:Column: 0 1 ... 31
Row 0: >00 >01 ... >1F Row 1: >00 >01 >1F Row 2: >00 >01 >1F Row 3: >00 >01 >1F
Row 4: >20 >21 >3F
...
And the pattern table would look like this (letters a-z represent the color of a given box, i.e. a digit in the range >0-F):Byte: 0 1 2 3 4 5 6 7Row: 0 1 2 3___
Entry >00: >ab >cd >ef >gh >ij >kl >mn >op
Entry >01: >qr >st >uv >wx >yz ...
...
This mode is fairly complicated to use (and does not yield very interesting results). A way to simplify it is to fill the screen with fixed character numbers, as shown in the above example. Drawing is then achieved by changing the color values in the character pattern table. Arranging the character numbers as in the example makes easier to calculate which byte must be changed in the pattern table, but there are other solutions.
Bitmap mode (Graphics II)
I'm sure every TI user had this great idea one day or the other: "Hey, lets fill the screen with all available characters: 0, 1, 2, etc. Then I can draw pixel-by-pixel by just changing definitions in the character pattern table". If you have tried, you must have realised there is a big problem: with 256 characters, we can only cover 1/3 of the screen. Not to mention the fact that the color table defines 8 characters at a time, which makes color drawings almost impossible. Bitmap mode takes care of these problems (sort of).
This mode is selected by setting bit 7 of register 0 as 1. Bits 3 and 4 in register 1 should be 0. VR0: 1 VR1: 0 0
In this mode, the screen is still devided in 24 row of 32 character, just as in standard mode. However, we now have three character pattern tables, one after the other: the first table applies to characters displayed in the top third of the screen (i.e. the first >100 bytes in the screen image table), the second to characters displayed in the middle third (bytes> 100-1FF) and the third to characters displayed in the bottom third of the screen (bytes >200-2FF in the screen image table).
Now we can fully cover the screen with non-redundent characters, by just writing >00, >01, >02 ... >FF three times in the screen image table. As the three pattern tables are consecutive, it is easy to calculate which byte is to be accessed to modify a given pixel.
There are also three color tables, arranged in the same way as pattern tables. Each entry in a table is eight bytes long and defines the colors for one character. Each byte in an entry defines the colors of a row in the character: the first nibble sets the pixel color for bits that are set as 1 in the pattern (foreground), the second sets the pixel color for the 0 bits in the pattern (background). The major drawback of this system is that each line of pixels in the display is chopped into 8-pixels clusters for which there is only a choice of two colors. This forces us to pay a lot of attention when drawing complex images, as 3 colors in a given pixel line must be at least 8 pixels appart.
Sprites are available in bitmap mode and work just as in standard mode.
Not so surprisingly, bitmap mode is extremely memory-hungry: it requires> 3300 bytes, not counting sprite tables.
To summarize, here is an example showing the correspondance between screen, pattern table entry and color table entry:Screen Pattern table Color table B 1 B B B B B 1 0 1 0 0 0 0 0 1 1 (black) B (l.yellow)B B 7 B B B 7 B 0 0 1 0 0 0 1 0 7 (cyan) BB B B C B C B B 0 0 0 1 0 1 0 0 C (green) BB B B B E B B B 0 0 0 0 1 0 0 0 E (gray) BB B B B 8 B B B 0 0 0 0 1 0 0 0 8 (m.red) BB B B B 5 B B B 0 0 0 0 1 0 0 0 5 (l.blue) BB B B B 6 B B B 0 0 0 0 1 0 0 0 6 (d.red) B2 2 2 2 D 2 2 2 0 0 0 0 1 0 0 0 D (magenta)2 (m.green)
The VDP register setting could be the following:
VR0 >02 Bitmap mode on
VR1 >C0 16K, screen on
VR2 >08 Screen image at >1800 (we can't have it at >0000 since either the pattern or the color table must be there)
VR3 >FF Color table at >2000, address mask = >1FFF (full size table: 3 times >800 bytes)
VR4 >03 Pattern table at >0000, address mask = >1FFF (full size table: 3 times >800 bytes)
Hybrid bitmap modes
Note that the trick of covering the screen with three repeats of characters 0-255 is just an easy way to calculate which byte corresponds to which pixel, this is by no means an obligation. You could use the tables just the way you do in standard mode: having fixed pattern definitions (and colors) and placing a character number in the screen image table to display it. The address masking trick becomes very handy in this case. Rather than having three copies of the pattern table one after the other, let's just have one and set the address mask to 0: in the example above, VR4 would become >00. The advantage over standard mode is that we can set different colors for each character (rather than for a group of
. In fact, we can even set a color pair for each pixel row in a character: this is a nice way to create iridescent characters!
Finally, both solutions can be mixed in the various thirds of the screen: the top two thirds could be arranged for easy bitmap drawing, whereas the bottom third could be arranged for rapid character writing. Some games use this solution to display prompts and scores at the bottom (or top) of the game screen.
You can use the mask bits in register 4 to assign a >800-byte pattern table to each third of the screen:
> 00 (or >04): only one pattern table, identical for each third of the screen.
> 01 (or >05): two pattern tables. One at >0000 (or >2000) for the 1rst and 3rd thirds, one at >0800 (or >2800) for the middle third of the screen.
> 02 (or >06): two pattern tables. One at >0000 (or >2000) for the 1rst and 2nd thirds, one at >1000 (or >3000) for the bottom third of the sceen.
> 03 (or >07): three pattern tables. One at >0000 (or >2000) for the 1rst third, one at >0800 (or >2800) for the 2nd third and one at >1000 (or >3000) for the bottom third of the screen.
Then we could do the same for the color table, using bits 1 and 2 (weight> 40 and >20) to select the number of tables. The remaining bits will affect character grouping within a table. Since they also affect grouping whitin the pattern table, we'd better be carefull with these!
In summary, these would be the addresses of the tables in 8 possible situations:
VR3 VR4 Mask Top 3rd Middle 3rd Bottom 3rd >1F >00 >07FF >0000 >0000 >0000 >9F >04 >07FF >2000 >2000 >2000 >3F >01 >0FFF >0000 >0800 >0000 >BF >05 >0FFF >2000 >2800 >2000 >5F >02 >17FF >0000 >0000 >1000 >DF >06 >17FF >2000 >2000 >3000 >7F >03 >1FFF >0000 >0800 >1000 >FF >07 >1FFF >2000 >2800 >3000
To group characters within a table, we could further alter the color table mask:- VR3 = >0F results in >400-byte tables. This means that characters> 80-FF will have the same colors and definitions than characters> 00-7F.
- VR3 = >07 results in >200-byte tables. This means that characters> 40-7F, >80-BF and >C0-FF will have the same colors and definitions than characters >00-3F.
- At the extreme, VR3 = >00 results in >40-byte tables. As there are 8 bytes per characters, this means characters are arranged in 8 groups of 32 identical characters: chars 0-7 are identical to chars 8-15, 16-23, etc.
- We could even get weird grouping schemes by using values like> 02,> 04, >55, etc.
The table below lists the six most logical values, plus two gooffy ones (just for fun).
VR3 Mask Character grouping Chars Repeats >00 >003F 0=8=16...=248
1=9=17...=249
7=15=23...=255 8 32 >01 >007F 0=16=32...=240
1=17=33...=241
15=31=47..=255 16 16 >03 >00FF 0=32=64...=216
1=33=65...=217
31=63=95...=255 32 8 >07 >01FF 0=64=128=192
1=65=129=193
63=127=191=255 64 4 >0F >03FF 0=128
1=129
127=255 128 2 >1F >07FF Each char is unique 256 1 >02 >00BF 0=8=32=40...
4=12=36=44... 16 16 >04 >013F 0=8=16=24=64...
32=40=48=56=96... 16 16
Bitmap text mode
This is the mode TI forgot to tell us about. It works just like standard bitmap mode, except that the screen is now 40 columns and that only two colors are available.
This mode is selected by setting bit 7 of register 0 as 1. Bit 4 in register 1 should be 1. VR0: 1 VR1: 0 1
The screen is now divided in three, each third is 8 lines high and thus occupies >140 bytes in the screen image table (8*40=320).
The colors are taken from VR7, just like in regular text mode. There is no color table, and the contents of VR3 is irrelevant.
Just like in standard bitmap mode, there can be upto 3 pattern tables, located either at >0000 or at >2000. You can use the address mask bits in VR4 to determine which third of the screen uses which table. The main difference is that the color address mask is not used to fill-in the patten address mask: >07FF is always used instead. No character grouping to worry about, then! This mode comes handy for black-and-white drawings.
Bitmap multicolor mode
Another undocumented mode. It works as a mixture of bitmap and multicolor mode.
This mode is selected by setting bit 7 of register 0 as 1. Bit 3 in register 1 should be 1. VR0: 1 VR1: 1 0
The screen is now divided in three, each third is 8 lines high and thus occupies >100 bytes in the screen image table (8*32=256).
Just like in standard multicolor mode, there is no color table and the contents of VR3 is irrelevant.
The color of the boxes are taken from upto 3 pattern tables, located either at >0000 or at >2000. You can use the address mask bits in VR4 to determine which third of the screen uses which table. Since a single table would be sufficient for this purpose, there is no real point in using this combined mode...
Illegal modes
It is not allowed to set text and multicolor mode together, whether in bitmap mode or not. VR0: x VR1: 1 1
If you try, the VDP will display a fixed image, that is not influenced by the contents of the VDP memory, nor by registers VR2 to VR6 (sprites are not available). The screen is 192 pixel lines and 40 columns. Each column is made of 4 pixels in foreground color, followed by 2 pixels in backgroud color. These two colors are taken from VR7.
Sprites
Sprites are special characters that can be displayed at any position on screen, i.e they are not limited to a grid or rows/column, instead each sprite position can be defined with a precision of one pixel.
Sprites can be either 8x8 pixels or 16x16 pixels depending on the setting of bit 6 in VDP register 1: when this bit is 0 all sprites are 8x8, when it is 1 all sprites are 16x16. In addition, bit 7 in VDP register 1 provides a mgnification feature: when this bit is 1 all sprites are magnified by a factor of two. Concretely this means that each "pixel" becomes a 2x2 pixels box.
Each sprite can have its own foreground color. The background color is always transparent, which lets the underlying image appear under the sprite.
Upto 32 sprites can be displayed at a time. Each one can be seen as an extra image plane on the top of the screen, overlapping each others, with sprite number 0 at the top. Thus the virtual image planes are:
- Black
- External video
- Backdrop plane (color in VDP reg 7)
- Image plane (characters)
- Sprite number 31
- Sprite number 30
- etc upto:
- Sprite number 0
There is one restriction however: the VDP cannot display more than 4 sprites on a given line of pixels. Thus, if 5 sprites or more must be drawn on the same line, only the topmost four (those with the smallest numbers) can be displayed. The number of the 5th one is placed in the status register together with a flag bit and the others are ignored. This occurs whether or not the sprites are actually overlapping: one could be on the left of the screen, the other on the right with the same result.
Coincidence is a different condition: whenever two "on" pixels in different sprites occupy the same screen location, a bit is set in the VDP status register. This comes handy for games programming: an easy way to check whether the bullet hits the target. Note however that the VDP does not tell you which are the overlapping sprites...
Sprites characteristics are defined in two tables pointed by VDP registers 5 and 6: the sprite attributes table and the sprite patterns table.
Sprite attributes table
This table is pointed at by VDP register 6. It contains upto 32 entries for the 32 sprites arranged in numeric order. Each entry is four bytes long, thus the maximum size for this table is >100 bytes. The four bytes define sprite characteristics as follows:
Byte 1 Byte 2 Byte 3 Byte 4 Sprite 0 vertical position -1 horizontal position pattern number clock bit sprite color Sprite 1
"
"
"
"
"
Sprite positions are expressed in pixels relative to the top left corner of the display area. This will be the position of the top leftmost pixel of the sprite (unless the early clock bit is set, see below). Note that the vertical position coordinate in the table is offset by one: therefore the topmost pixel line is >FF, the second is >00, the third is> 01 and the last is >BE. Any sprite whose vertical position is greater than> BE won't be visible on screen, although coordinates close to >FF can result in the bottom of the sprite appearing at the top of the screen. Similarly, row values just under >BE result in partly blending off the bottom of the sprite.
The same thing is true for sprite approaching the right border of the screen (horizontal coordinates close to >FF): the sprite appears to blend-in from the right. However this won't work on the left of the screen: when the horizontal position is 0 the whole sprite is visible, when it's lower than 0 (i.e. >FF, >FE, etc), the sprite appears at the right of the screen. To allow for sprite blend-in from the left of the screen one can set the "early clock" bit (bit 0, value >80) in the color byte: the horizontal coordinate now refers to a point located 32 pixels to the right of the upper left corner of the sprite. This results in shifting the sprite 32 pixels to the left and allows for partial disappearance on the left side (but not any more on the right).
The pattern number refers to the entry containing the sprite pattern in the sprite pattern table.
Finally the sprite color is defined by the right nibble in the byte 4 of the entry.
The sprite attributes table does not need to define all sprites: if the vertical position of a sprite is set as >D0, the sprite won't be displayed (as it's off-screen), but neither will any of the following sprites. This comes handy to quickly erase all sprites by just changing one byte in the attributes table.
Sprite pattern table
This table contains patterns to be used by the various sprites, arranged in ascending order. Each entry is either 8 bytes long or 32 bytes long depending on the sprite size.
If the sprite size is set as 8x8, entries are 8 bytes long. Each byte defines a row in the sprite: "1" bits result in pixels of the color specified for that sprite in the attributes table, "0" bits encode transparent pixels and are ignored for display purposes.
If the sprite size is set as 16x16 (VDP register 1, bit 6 set as 1) each entry is 32 bytes long. These bytes define the sprite pattern as if it were made of four "normal sprites" arranged in a 2x2 formation:
1 3
2 4
Thus, bytes 0-7 define the top left quadrant, one byte per line of 8 pixels. Bytes 8-15 define the bottom left quadrant in a similar fashion. Bytes 16-23 define the top right quadrant, one byte per line of 8 pixels (which now corresponds to pixels 9-15 of the sprite rows 0-7) and bytes 17-23 define the lower right quadrant.
Even wiith a 16x16 pixels size, 32 sprites require at most >400 bytes (32x32). Thus there is room enough for extra sprite patterns and a sprite can be animated by quickly changing its pattern number in the attributes table rather than by modifying the sprite pattern table.
Timing issues
The VDP needs 2 microseconds to read or write a byte to its RAM. In addition, it can only communicate with the CPU at precise moments, when it is not too busy with building the screen. Such moments are known as CPU access windows and may arise at various intervals depending on the video mode. In standard or bitmap mode, a window occurs every 16 memory cycles, each cycle being 372 ns long. This means the VDP may have to wait upto 5.95 us before a CPU access window occurs. Adding the 2 us needed for RAM access gives us a maximum delay time of 8 us. Of course, it can be as fast as 2 us if a window just happens to open (even less for reading operations, thanks to the read-ahead buffer). In text mode, a window opens every three memory cycles, i.e. at intervals of 1.1 us. In multicolor mode, a window opens every four memory cycles, i.e. at 1.5 us intervals.
There are two exceptions to these rules, however:- When the screen is blank (because bit 1 in register 1 is set as 0) the VDP does not handle the screen and a CPU access window is permanently open. Consequently, there is no wait time.
- When the VDP is done with drawing a frame and enters vertical refresh mode it issues an interrupt (if enabled) and opens a 4.3 milliseconds (4300 us) window for CPU access.
Condition Mode RAM access
delay Time waiting
for a window Total delay Building screen Standard
/ Bitmap 2 us 0 - 5.95 us 2 - 8 us Building screen Text 2 us 0 - 1.1 us 2 - 3.1 us Building screen Multicolor 2 us 0 - 1.5 us 2 - 3.5 us Vertical retrace Any 2 us 0 2 us Blank screen Any 2 us 0 2 us
Contrarily to standard memory, the VDP cannot hold the CPU in a wait state until it is ready to accept/send data. This means that the application program must contain appropriate delays to prevent the CPU from going on with the next operation before the VDP has completed the current one. A typical example is passing the two command bytes to the VDP: using two successive MOV instructions is too fast and the second byte won't be read. The program should thus contain another instruction in between the two MOV (such as a NOP or a SWPB).
Programming examples
*------------------------------------------------------------* VDP write to register. * Expects register # in R0 MSB and register content in R0 LSB*------------------------------------------------------------VWREG ORI R0,>8000 Set command bits as 1xxx xrrrCMD SWPB R0 Send a command to the VDP MOVB R0,@>8C02 Send first byte (least significant) SWPB R0 Delay MOVB R0,@>8C02 Send second byte (most significant) B *R11*------------------------------------------------------------* VDP set address to write in RAM* Expects address in R0*------------------------------------------------------------VAD2WR ANDI R0,>7FFF Make sure command bits are 01xx xxxx ORI R0,>4000 JMP CMD Send command*------------------------------------------------------------* VDP set address to read from RAM* Expects address in R0*------------------------------------------------------------VAD2RD ANDI R0,>3FFF Make sure command bits are 00xx xxxx JMP CMD Send command*------------------------------------------------------------* VDP write byte to RAM* Expects data byte in R0 MSB and address set by VAD2WR*------------------------------------------------------------VWRBYT MOV R0,@>8C00 Send data to VDP B *R11 Delay*------------------------------------------------------------* VDP read byte from RAM. Assumes address was set by VAD2RD* Result will be in R0 MSB*------------------------------------------------------------VRDBYT MOV @>8800,R0 Get data byte B *R11 Delay*------------------------------------------------------------* VDP read status. Result will be in R0 MSB*------------------------------------------------------------VRDSTA MOV @>8802,R0 Read status register, resets bits 0-2. B *R11 Delay
- Read more...
- 0 comments
- 5
-
Latest Entry
Firmware Vx.40
Hello all,
after almost 3 years a new Firmware is ready for download.
And yes, you remember correct, i started the entry 3 years ago with similar wording.
What is new?
- the content is shown in the menu
- auto-size mode for *.lnx-files
- modify up to 128Bytes at once for 93Cx6 chip
- code optimation (e.g. Flash erase routine)
- Support of 93C66 and 93C86* for all functions with USB (93C66 and 93C86* was requested from some developers - *93C86 only for Board 6)
- only Board 1 with PCB 1.3d4:
- bank mode available - 2 independet banks with 512KB (possible to switch back to fast-erase mode as before)
- It is possible to switch between the banks if the FlashCard is inserted into the Lynx. As long as the LED is flashing, it is possible to press Anykey to change to the other bank.
- To use the changed bank, the Lynx must be switched off and on again.
- only Board 1 with PCB 1.3a4 limited edition:
- optimation of demo cancle - the FlashCard do no longer start up the demo again if the demo is cancled to early (only 25th anni!)
- If the FlashCard is inserted into the Lynx, it is possible to activate and deactivate the demo as long as the status LED is flashing by using the Ankey
- To use the changed demo setting, the Lynx must be switched off and on again.
- Easteregg
Please use "Firmware V140N 20160107 Language V140x.fcb1" for Board 1 FlashCard.
(PCB V1.271/1.276/1.280/1.3a4/1.3d4)
Please use "Firmware V640N 20160107 Language V640s.fcb6" for Board 6 FlashCard.
(PCB V1.913/1.923)
Please note: at first use after Firmware update the FlashCard will ask to press the Anykey to initialize some parameters.
The FlashCard only accept a Firmware file which work with the FlashCard! If the FlashCard do not accept you tried the wrong Firmware file!
For details about the update please read the manual!
The manual is available in English (en) and German (dt).
Kind Regards
LynxmanFlashCard Manual 1_40_en.pdf FlashCard Manual 6_40_en.pdf FlashCard Manual 1_40_dt.pdf FlashCard Manual 6_40_dt.pdf Firmware V140N 20160107 Language V140x.zip Firmware V640N 20160107 Language V640s.zip
-
After 5 years of collecting I finally got one of the games I wanted from the beginning, Halloween on Atari 2600. The version I decided to finally purchase was the game with no label. Just a white sticker with the word "Halloween" written in orange across it. The story behind this version was that Wizard Video was liquidating their inventory so in order to save money they stopped producing labels and just wrote the names of the game on the cartridge. This raises an interesting question which i've never really seen an answer for. Which version is more rare? Of course the rarity guide has the no label version at an 8 and the label version at a 7, but in the description of the non label version it reads, "It is not clear which one is more rare"... Well in my 5 years of looking for this game waiting to finally get one for my collection I have seen a lot more labeled versions than non labeled versions for sale on the internet. Now this doesn't exactly mean that the non label version is more rare, but it stands for something. In the 5 years of collecting I have seen the label version for sale in a retail store but have NEVER seen the no label version for sale. It is a very compelling argument that I do not have a confident answer for. If I were to give my best guess from what i've seen over the years the no label version is more rare and hard to find. Either way it is unclear how many of these carts are out there and it remains one of the hardest to find games in the atari 2600 library.
- Read more...
- 0 comments
-
- 3
entries - 2
comments - 4790
views
Recent Entries
Latest Entry
Scott Adams
Scott Adams is a familiar name in the TI community, outside of this community one could mix him up with the other Scott Adams who writes comic strips about Dilbert and although they are both story tellers in some way our Scott is not just a story teller but an expert coder and creator of the adventure style games.
Scott Adams, the genius behind many Text adventure games was brought up in Miami Florida. In 1975 he wrote a computer game on a computer that his brother Richard built a year before, making him the first person on earth to write a computer game on a home computer. The full story of how Richard came to build this machine, well before Steve Wozniac built Apple 1 can be read in great detail in the link below:
http://exoticsciences.com/sa.htm
The following is a writeup given to me directly from Scott Adams himself. At first I intended to polish it up but then I realised that this in itself is a part of history that should remain as intact as possible.
"I grew up in North Miami Beach and always had a love for science, I remember as a child in the early 60s going on a tour of the University of Miami and seeing the computer science department and waiting to go inside. I was active in local science fairs and won some awards as well as being written up in articles in the newspaper. IN high school as an experiment the state of Florida allowed one remote terminal in our high school math lab to the U of M mainframe and it was running APL/360. My first major program was tic tac toe that would always win. I would go into school before it opened and had permission to be let in by the janitors and after school I would stay until late, locking up the school behind me.
My brother build from chip slice cpus a homebrew computer which I then programmed in machine language a game for (more info on my webpage on a sidebar on this). I also had the first ever Sphere computer homekit which I then proceeded to mod with a my own designed graphics card and wrote a tank war game for. I won the first ever “what do you use your Sphere for” contest with the company.
I was working at Stromberg Carlson in lake Mary Fl as a software engineer when I purchased my first “appliance” computer, ie a computer I didn’t have to build to use J I wanted to learn the BASIC language on it and thought the concept of strings was interesting so I wanted to write a game that let you use English language somehow. At work the IT dept got a copy of Crowther and Woods Adventure! And I was able to get a password to play it. I came in all week before work ad stayed at night to play until I beat it. I decided I want to write a similar game for my TRS-80 model I. Other engineers there laughed at me and said this was running on the mainframe and my toy computer could never handle it. I ended up invented my own language which I emulated in BASIC and wrote my first Adventure game.
Before Stromberg, I got my degree in Computer Science for Florida Institute of Technology (now known as Florida Tech). I worked downrange on the Air Force Eastern Test Range as a Space Object Identifier Analyst at radar stations. But there was a mainframe there and I loved to program so I got permission to make some major mods to the software they were using even though I wasn’t hired as a programmer. I got a number of commendations for some things I did. At one radar station on Antigua Island they only ran it for the day shift, so I was able to use the machine in the evenings for myself. I got a copy of a Fortran Star Trek game that played on the teletype. I then proceed to covert it to run on the radar screens instead and in effect turned the multi-millionaire dollar radar tracking station into a giant video game J great fun.
Return to Pirates Island was written in my own proprietary database adventure language like all my adventure games. I wrote them on one machine then transferred the databases to other machines to execute. RTPI was special in it was originally only for the TI and also was the world’s first adventure game to have graphics in a game cartridge. I also developed a special program to be able to get the graphics to fit. Instead of graphical compression as used today I came up with making the pictures of pieces of other pictures and then having an artist make this picture based on these smaller pieces. It ran very fast but was very labor intensive for the poor artist as you might imagine."
I thank Scott for sending me this small Bio. He is a very humble and inspiring person, one who gave us many hours of entertainment and made our world a little better.
- Read more...
- 0 comments
- 3
-
- 17
entries - 6
comments - 7261
views
Recent Entries
Latest Entry
11/30/15 - Photograph
I've been busy and could not think of who sang this song. It finally hit me yesterday so I'm putting it up. For the past 10 days, my sleeping habits have been horrible and I can't say any one song has been there when I woke up. So there are no entries from 12/1 to 12/10. This was the one on 11/30, so I"m posting it. I knew the song, couldn't find it when typing the title, until I remembered the band. It is Photograph by Def Leppard.
Phil
- Read more...
- 0 comments
- 17
-
Latest Entry
This is my blog introduction. read it
um hello. This is my blog. I like to play games and stuff. Call of Duty is one of my favorite series ATM. Xbox 360 is my main console but I also play on mobile, Game Boy Advance SP, super nintendo, PS2, Wii, and Atari 2600 as well as Plug N Plays every once in a while. I also love Star Wars. This is all I have time to write. I will hopefully do more entries later. Bye readers!
- Read more...
- 0 comments
-
- 4
entries - 0
comments - 14822
views
Recent Entries
Some days ago, while listening to some of the Zelda II soundtrack, I noticed something - it's possible you may have noticed it too. Zelda II's soundtrack sounds inherently different from the original Zelda. And not just due to the composer, either - (Koji Kondo in The Legend of Zelda, while Akito Nakatsuka did the music for Zelda II: The Adventure of Link in his only Zelda compositional work. Interested readers may like to know that his Dungeon Theme from the game was used as the StreetPass Battle Theme in The Legend of Zelda: A Link Between Worlds. Rather the remix [as it is now orchestral] was done by Nakatsuka himself or the game's composer Ryo Nagamatsu is unknown, but I am of the opinion that it is the work of Nagamatsu as Nakatsuka does very little compositional work these days.) -it sounds like it's using different 8-bit 'instruments' from the original Zelda.
A portion of this may be down to the technique of the composers. I however and of the opinion that this down to the sound programming - in particular, the sound driver used. You see, in these early days of gaming, there was no standardized software. Composers were often also proficient programmers, so each composer might program his own sound driver. Of course, you'd get the rare occasion where a programmer would have to do the music as they couldn't afford a composer, but we do not speak of these.
I did some digging at this website for information, having stumbled upon it months ago and remembering a mention of sound drivers. And with that - success! Nintendo used three sound drivers on the NES. The first was programmed by Hirokazu Tanaka (at the time he started working at Nintendo, there was no sound driver for the Famicom, so he programmed one himself), the second by Akito Nakatsuka (initially he used Tanaka's before programming his own around 1986.) and the third by Koji Kondo (Nintendo required its main composers to write their own sound drivers, so Kondo did likewise). It is safe to assume that Kondo used his own sound driver for his Zelda music, thus, given the different sound of the Zelda II soundtrack, one can only guess that Nakatsuka likewise used his sound driver for Zelda II's music.
A mystery solved. But one does wonder: what games had what sound driver? Kondo's (and possibly Tanaka's and probably many, many other company's sound drivers) fit the definition of 'classical' 8-bit music. Nakatsuka's doesn't. Metaphorically, it's the sitar to Kondo's pizzicato violin. Going off of only the Zelda game's, Nakatsuka's is immediately different from the first Zelda, and thus, Kondo's driver. One further distinction is that his driver seems peculiarly weak at the higher pitches, as the Zelda II title theme shows off.
Something to wonder. Perhaps one day we may know, either through guesswork or someone managing to get their hands on information straight from the Yoshi's mouth.
- Read more...
- 0 comments
- 4
-
Recently Browsing 0 members
- No registered users viewing this page.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord