acadiel

Keep up the peer pressure, folks :-) :-) :-) :-) :-) :-)

Jeff, maybe I should have clarified... remember when we were working on the V9T9 and PC99 disk images and finally got the conversion to HFE correct? If the OP was using a really old version of the conversion program, it's quite possible they were running into issues with this.

Yep, seconded with ti99erclub's info.. make sure you have the latest firmware. Older versions of firmware had issues. Also, earlier versions of the HFE conversion programs didn't work properly either. PC99 and V9T9 disk images should work fine and be transformed into HFE files before use. Also, have you tried emailing Jeff with the HxC project directly? hxc2001 at free dor fr

Marc, you always come out with interesting time sinks... Hehehe... I'll have to transfer this to my TI and play with it. Thanks!

Yep, it's yours! PM me your address again and I'll package it up for ya...

I have a CF2K cartridge (v1.4) meant for the original CF2K (the parallel port one). I got rid of that parallel port CF2K, but still have the cart. I suppose I could recycle the board, reprogram the EPROM and make a new label, but I figured I would check to see if someone needed it first. If anyone, wants it, let me know. $25 USD shipped to the US. This is only for the board, EPROM, and cart case. I'm not "selling" CF2K.

The new 512K/GROM cart will provide all the functionality this cart did and more

The ROM functionality is there with 512K and a 74LS378. Tursi is still working in the GROM parts. (Prod, prod....)

IMHO, this is just my opinion, but the C64 had a few things going for it from what I read in the book: 1) Custom built video and sound chips that allowed a lot of tweaking, non standard "hitting the hardware", etc 2) Fully documented architecture/schematics (at first release) whereas with the TI, that did not seem to happen until later. This enabled a lot of peripherals. It also had its own issues... 1) the high speed lines to the external disk drive were removed by someone before the boards were mass produced, so they had to kluge the disk drive access with fewer lines, which made it much slower. 2) The BASIC commands were rather cryptic. Just look at the load command to load a program! Ex: LOAD "*",8,1 Every computer during those days had its own quirks.... I was amazed after reading the book that the C64 seemed to have its own colorful ones just like our TI does.

Mine's still on preorder at Amazon....

I wonder if we can hack Telco to toggle the 80 column text mode on the F18A Richard, still have that source?

Will Telco 80 column work with the F18? Anyone tried yet?

Here are the schematics for it, too. Schaltplan-SuperModul.pdf Supermodul.pdf

Actually, I'm guessing it probably could be consolidated quite a bit with modern technology, especially all those 74LS chips. I haven't had time to look at redoing it though.

You know... it wouldn't be too hard for Custudio to put a PGram function on one of those.... :-)

Wow, it's up to $365.

Speaking of the GK, did Craig Miller or CaDD ever release the schematics?

I know the guy selling it, Ernie. He's a great guy! Whomever wins it can be rest assured that it was well taken care of.

The cheap $49 Craig 15" LCD that I have doesn't seem to pass through audio while on the VGA input. Kind of sucks, if you ask me. In the meantime, I have one of these hooked up... http://www.radioshack.com/product/index.jsp?productId=2062620

Ending soon

And what would explain the inconsistent results between the two cartridges. Your bank switch testing program you authored really helped me out on this!!! Thanks! I'm a fan of the 74LS378, because I haven't had issues with it, but if we can get the GAL working properly and fix whatever the issue is, I'm not against using it either. Matthew - thoughts? Since I know you did build a GAL that did bank emulate the 74LS379 and it did work.

Yeah, but it actually has some space in it's memory map to where we don't have to cannibalize something else.. 0x0000 - 0x1FFF BIOS 0x2000 - 0x5fff Unused 0x6000 - 0x7fff RAM 0x8000 - 0x8000 Cartridge ROM I don't remember the missing lines from the cartridge port offhand (but if someone does, please note them below) that are present on the right hand expansion bus, but it keeps us from offering RAM in the full range on the cart port. Someone, please jog my memory.... On an unexpanded system, could we slap some RAM in >2000, >4000, and >6000? >6000, definitely, but am not sure about >2000 and >4000. There wouldn't be 32K or DSRs hanging out on an unexpanded system's memory map, after all.

My last one is up for auction... eBay Auction -- Item Number: 200820128008

Hey Matthew - with the GAL version; any idea why I'm getting different bank results on the identically programmed GAL on two carts? I saw the inverse worked ok on the cart.. it's the non inverse that's giving me issues.

It would be good in certain cases. There are pros and cons, and both are easily debated. Pros: The extra RAM to hold high score counters, buffers, 'working area' (instead of VDP) would speed up some games. No need to buy a Nano PEB to get extra RAM to run a game that needs that working space Cons: When we start doing 4K/4K or 6K/2K boundaries, we lose backward compatibility, and have to start coding on non 8K boundaries (i.e. >6000 to >77FF is ROM only, and >7800->7FFF is RAM). Willsy does mention a switch to disable, above. Essentially, only newly written programs that were written on these boundaries would work properly. Bank switching could be done, but then you lose 2K of each 8K segment unless we really try to fudge and divide into 6K segments (i.e. 64K = 6K x 10) or disable it. Not sure if doing that math is hard or easy. That kind of memory map (split) will only work with that one particular board. Kind of like the proprietary SuperSpace of days of old, except no CRU bank switching. RAM is tied to the cartridge; instead of using a Nano PEB or something else for RAM. With the flexibility that Tursi is building into the AVR with GROM/GRAM and the added ROM, the 512K cart will fill a niche of allowing traditional programs to run, while giving others physical form for the first time (ala RXB, Plant Genetics, Disney cartridges like Peter Pan, Pinocchio, etc.) Most folks will likely be using the 512K cart as a development cartridge (in which case they will already have a Nano PEB, memory expansion, etc), a ROM cart (without the AVR), to give aforementioned software-only cartridges physical form, or as a super-uber-yet-undetermined function. The possibilities are pretty endless, except for the RAM. I'd say if we really want to do something cool, we could also make a "super nano PEB" that's just a 32K dongle that fits on the side of the console, so folks don't have to open and modify the system to add 32K to stock systems. It could be super cheap, and I have a prototype in ExpressPCB somewhere if I can find it.