Jump to content
IGNORED

.BIN Repository - Images for cartridges that require "burning" - (NO LONGER UPDATED OR SUPPORTED)


Omega-TI

Recommended Posts

Yeah, Fred's HDX server is something I could NOT do without. Actually when you have an HxC and an HDX working together it's like milk & brownies, peanut butter & jelly or wine and cheese. They compliment and enhance each other to the point that once you pair the two there is simply no going back.

Link to comment
Share on other sites

Yeah, Fred's HDX server is something I could NOT do without. Actually when you have an HxC and an HDX working together it's like milk & brownies, peanut butter & jelly or wine and cheese. They compliment and enhance each other to the point that once you pair the two there is simply no going back.

*chuckle* Okay, I'll add the HDX project to the list. I need to finish a few other things first (Return to Pirate's Isle verification, Ron's BASICODE turbotape thingy), but I just found Fred's HDX protocol description and I now think the software side won't be very tough at all icon_smile.gif

Link to comment
Share on other sites

*chuckle* Okay, I'll add the HDX project to the list. I need to finish a few other things first (Return to Pirate's Isle verification, Ron's BASICODE turbotape thingy), but I just found Fred's HDX protocol description and I now think the software side won't be very tough at all icon_smile.gif

 

the exe runs fine under wine, i just had to set up a com1 symlink in the dosdevices dir to point to my comport and add the user to the dialout group

Link to comment
Share on other sites

Doh.

 

I'll post a file as read from my TL866 later today. Didn't even think about that, got distracted following the HxC conversion problem down the rabbit hole ...

 

... edit: attached. It's only the stuff needed to burn the cartridge, plus Multiplan's .dsk. Set fuses the same way as documented elsewhere, or you can try to use the included config file (read from the 1284P)

 

Thanks for reminding me that I could just read the whole thing with the TL866. Should have thought of that ...

 

Burned and tested here works great!

 

Greg

  • Like 1
Link to comment
Share on other sites

the exe runs fine under wine, i just had to set up a com1 symlink in the dosdevices dir to point to my comport and add the user to the dialout group

Cool, and I might bootstrap/verify my setup initially that way.

 

Unfortuntely, wine doesn't run the Windows x86 ABI on ARM. I have a dedicated BeagleBone Black attached to my console as a cassette emulator and host server for serial XMODEM transfer; it would be nice to use it as a HDX server as well.

 

I very much do not like closed-source programs, especially one that expect Windows ABI. You never know when the Codeweavers guys are going to "improve" something and break compatibility -- for example, I run classic99 through the "legacy X server" option on MacOS because the "performance graphics" option eats keystrokes, and that's a relatively new phenomenon.

 

I very much do like open-source cross-platform programs, especially one that seems as useful as HDX. That's why I'm glad that Fred documented his protocol; this can be done in a couple of hundred lines of python (if even that much), it will run anywhere, and since it's interpreted it's by definition open-source.

 

Need to finish sourcing parts for the mod, though.

Link to comment
Share on other sites

Burned and tested here works great!

 

Greg

Oh, fantastic. Feel free to offer that as a burn option on your store site. I kinda sorta doubt that many people will want it, but it's good to have options.

 

Okay, guys ... what other GROM or GROM+ROM modules do *you* want to see in the next multicart? Difficulty: not Terminal Emulator II, as the BASIC hooks seem to be incompatible with our ROM banking scheme. After RPI and Plato, I have five GROM slots free in the multicart ...

Link to comment
Share on other sites

There are several programs from TI that exist as GROM files but for which physical cartridges have never been available (or for which only a single prototype has been found). Examples: Plant Genetics, Lasso, Crossfire, the E.T. programs, the Disney cartridges, and the Key to Spanish cartridges. A couple of these have been hoisted into the multicarts, but by putting them into an UberGROM, they can be used without a 32K card, just as they were originally designed to be used.

 

There are also the other versions of Logo (Spanish and German) and Logo II (Spanish, French, German, Italian, and Dutch).

Edited by Ksarul
  • Like 2
Link to comment
Share on other sites

Yeah, Fred's HDX server is something I could NOT do without. Actually when you have an HxC and an HDX working together it's like milk & brownies, peanut butter & jelly or wine and cheese. They compliment and enhance each other to the point that once you pair the two there is simply no going back.

(threadjack)

 

*shrug* My mileage varied. I finally got mine running this afternoon, and spent the evening playing with it.

 

My conclusion is that the design could have been a lot better.

 

First off (and I know that others have raised similar questions) is the need for battery-backed RAM instead of putting the DSR into an EPROM. I understand a) the desire to lower the chip count, b) the HDX DSR using some of the RAM for local buffers, and c) the distaste for burning an EPROM during development ... but it's still a lousy design decision, especially in light of reports on these forums that the batteries last a few months at best.

 

(using an EPROM would obviate the need to cut the IRQ line, but that should be obvious to the most casual observer)

 

Second, his cable design doesn't work *even on RS232/1*. Here, too, I understand the desire to make the ports pin-for-pin compatible with the PC DB9 standard, but it does not work well. The right thing to do, and what I did, was to wire an all-DB25 cable per TI's documentation. That, in combination with a straight DB25-DB9 cable, resulted in two systems (one Linux running his HDX server via wine, and the TI) being able to talk to each other.

 

And then there's the protocol. Oh, lord, the protocol. The documentation bears only a passing resemblance to what's really happening on the wire. Take the DSR "am I connected to the server routine" ... it sends an undocumented 0x99, and needs that 0x99 appended to the server reply.

 

That server reply needs to happen immediately. The TI sends the probe *once*, and then if it doesn't receive a reply it sends a "#" (indicating "retransmit your last") about once per second for the next six seconds. If RX or TX took a hit during the initial probe, the server will never sync with the TI.

 

As far as I can tell, the various protocol operations are asynchronous except when they aren't. God forbid you don't ack an operation "0" immediately (opening HDX1 in DM2000), but DSK2PC streams thirty-six blocks (the lower-case "w" op) before it notices that the server didn't respond.

 

In summary: the HDX is a nice idea, but horrible execution. The protocol as implemented diverges from the protocol as documented, the implementation is not robust, and it is rapidly becoming untenable with the increasing scarcity of non-USB serial ports.

 

If I were recommending a setup to a new TI guy (which, given my location, would probably never happen), I would *not* recommend a HDX modification, full stop. Someone considering the HDX is going to have a PEB, and that PEB is more likely to have a floppy drive than a TI serial card. I would recommend a HxC and an 80-track EPROM over the HDX, especially if the person in question valued his time.

 

Just my two yen. Not impressed.

Link to comment
Share on other sites

Hi Ckoba,

I think we see things from two different perspectives. I'm from the 'user' camp, you seem to be from the 'developer' camp. I'm not qualified to comment on the programming and interfacing issues, I'll take your word for those apparent deficiencies. However, I'm still impressed. Why?

 

1 - The thing is twice as fast as a disk drive or HxC, so whatever implementation issues may be hidden away under the floorboards, they are simply overshadowed by this modifications speed and added utility. I've never had a complaint.

 

2 - The cost to benefit ratio makes this project very enticing.

 

3 - Simply from it's storage aspect alone, it's actually an obtainable piece of hardware, unlike rare items like SCSI cards. When you add it's added utility of being able to EASILY move things from the PC & Internet over to the TI... or... back, well, I love it. Then there is the printer option that is like icing on the cake.

 

4) - It's a project many are capable of doing themselves (if they want).

 

5 - The software makes it easy to setup and program, so changing the battery once every 9-12 months is not that big of a deal (at least to me). The operational software is mature, having already gone through multiple enhancements over the years. In short it's a well developed and mature package. I was using DM2K before I got my HDX and was quite pleased with it's compatibility, which makes sense considering it's author. ;-)

 

6 - There are enough people using them that help is easily available in case any issues arise. Just my two bits.

 

Oh - and I also recommend an HxC, especially for people with no RS-232 card in their P-Box.

 

 

A couple of reasons (besides basic storage) why I like it...

 

https://www.youtube.com/watch?v=s9UPvRFjQDA

 

https://www.youtube.com/watch?v=p8FdU0nzExA

 

Therre are more reasons, but I gotta go...

  • Like 1
Link to comment
Share on other sites

(threadjack)

 

*shrug* My mileage varied. I finally got mine running this afternoon, and spent the evening playing with it.

 

My conclusion is that the design could have been a lot better.

 

First off (and I know that others have raised similar questions) is the need for battery-backed RAM instead of putting the DSR into an EPROM. I understand a) the desire to lower the chip count, b) the HDX DSR using some of the RAM for local buffers, and c) the distaste for burning an EPROM during development ... but it's still a lousy design decision, especially in light of reports on these forums that the batteries last a few months at best.

 

(using an EPROM would obviate the need to cut the IRQ line, but that should be obvious to the most casual observer)

 

Second, his cable design doesn't work *even on RS232/1*. Here, too, I understand the desire to make the ports pin-for-pin compatible with the PC DB9 standard, but it does not work well. The right thing to do, and what I did, was to wire an all-DB25 cable per TI's documentation. That, in combination with a straight DB25-DB9 cable, resulted in two systems (one Linux running his HDX server via wine, and the TI) being able to talk to each other.

 

And then there's the protocol. Oh, lord, the protocol. The documentation bears only a passing resemblance to what's really happening on the wire. Take the DSR "am I connected to the server routine" ... it sends an undocumented 0x99, and needs that 0x99 appended to the server reply.

 

That server reply needs to happen immediately. The TI sends the probe *once*, and then if it doesn't receive a reply it sends a "#" (indicating "retransmit your last") about once per second for the next six seconds. If RX or TX took a hit during the initial probe, the server will never sync with the TI.

 

As far as I can tell, the various protocol operations are asynchronous except when they aren't. God forbid you don't ack an operation "0" immediately (opening HDX1 in DM2000), but DSK2PC streams thirty-six blocks (the lower-case "w" op) before it notices that the server didn't respond.

 

In summary: the HDX is a nice idea, but horrible execution. The protocol as implemented diverges from the protocol as documented, the implementation is not robust, and it is rapidly becoming untenable with the increasing scarcity of non-USB serial ports.

 

If I were recommending a setup to a new TI guy (which, given my location, would probably never happen), I would *not* recommend a HDX modification, full stop. Someone considering the HDX is going to have a PEB, and that PEB is more likely to have a floppy drive than a TI serial card. I would recommend a HxC and an 80-track EPROM over the HDX, especially if the person in question valued his time.

 

Just my two yen. Not impressed.

 

It works. It's not that hard to implement (making a splitter cable per the TI spec works great) and it isn't that hard to build. The battery backed DSR adds some complexity but being able to upgrade your DSR at will without technical requirements is the reason for it. Burning an Eprom is beyond a lot of people. Easy to criticize the protocol from the sideline. The fact is it's pumping data at 38400 from a TI card that can bearly do 9600 in standard interrupt without overrunning itself.

 

Greg

  • Like 1
Link to comment
Share on other sites

 

It works. It's not that hard to implement (making a splitter cable per the TI spec works great) and it isn't that hard to build. The battery backed DSR adds some complexity but being able to upgrade your DSR at will without technical requirements is the reason for it. Burning an Eprom is beyond a lot of people. Easy to criticize the protocol from the sideline. The fact is it's pumping data at 38400 from a TI card that can bearly do 9600 in standard interrupt without overrunning itself.

 

Greg

 

Right, so I was expecting this.

 

It works *only* if you disregard Fred's instructions about the cable (the TI is wired correctly for this application anyway, introducing two more cross-cables into the mix is idiotic)

 

The battery-backed DSR is a poor design decision; end-user field upgrades is only a byproduct of the original intent to shorten development turnaround time and be lazy about file buffering.

 

The 9902 can easily spit out 115200 half-duplex, so the HDX (which is supposed to be running half-duplex, but there is no handshaking with that damned "#" asking for retrans) isn't doing anything groundbreaking by running at 38400.

 

"Easy to criticize the protocol from the sidelines"? Ah, a variation of the old "show code or shut up". Fine. Attached is a quick python script that handles the server-side upload functionality of DSK2PC. It works on anything with a python interpreter, and it works with every USB dongle I've thrown at it. This represents two days of frustration with Fred's application via wine, VMWare, and a Windows 7 box I built just to watch what was really happening on the serial port.

 

Make sure this is running before you turn any of the TI gear on, and edit the bit at the top to reflect the path to your serial device. I'll add this to my github repo when it supports PC->TI .dsk transfer; perhaps someone as frustrated with Fred's Windows-only application will pick it up and add the bits that they need.

 

I think I've earned the right to criticize the protocol, sir, and I stand by my statement that I would not recommend the HDX to any TI user that values his time or tries to use currently-available gear as a server.

rx-server.zip

Link to comment
Share on other sites

(I dislike quoting entire posts, so I've taken the liberty of snipping your response a bit. I hope you don't mind.

 

I think we see things from two different perspectives. I'm from the 'user' camp, you seem to be from the 'developer' camp. I'm not qualified to comment on the programming and interfacing issues, I'll take your word for those apparent deficiencies. However, I'm still impressed. Why?

 

1 - The thing is twice as fast as a disk drive or HxC, so whatever implementation issues may be hidden away under the floorboards, they are simply overshadowed by this modifications speed and added utility. I've never had a complaint.

 

2 - The cost to benefit ratio makes this project very enticing.

 

3 - Simply from it's storage aspect alone, it's actually an obtainable piece of hardware, unlike rare items like SCSI cards. When you add it's added utility of being able to EASILY move things from the PC & Internet over to the TI... or... back, well, I love it. Then there is the printer option that is like icing on the cake.

 

4) - It's a project many are capable of doing themselves (if they want).

 

5 - The software makes it easy to setup and program, so changing the battery once every 9-12 months is not that big of a deal (at least to me). The operational software is mature, having already gone through multiple enhancements over the years. In short it's a well developed and mature package. I was using DM2K before I got my HDX and was quite pleased with it's compatibility, which makes sense considering it's author. ;-)

 

6 - There are enough people using them that help is easily available in case any issues arise. Just my two bits.

 

Oh - and I also recommend an HxC, especially for people with no RS-232 card in their P-Box.

 

We'll have to agree to disagree on this.

 

You think it's fine, because your setup works. That's okay. I think the protocol is poorly thought-out and the hardware is junk, because I've had to tear it apart to get it to work and I see how it looks from the inside.

 

I'm especially unimpressed with the battery-backup circuit -- the reason batteries don't last long in this thing is because the backup circuit tries to power the whole damned card when the PEB is turned off. This is the same reason that people are supposed to remove the MiniMemory when they're not using it, but that's hard to do when the card is in a PEB ...

 

... but that's okay, too. It's akin to the cassette cable issue; some people are happy with massive amplification and EQ presets to transfer from PC to cassette, because it works for them; others look at the design and say "wait a minute, that's a design flaw". The problem is when the two camps meet, because "users" and "developers" (as you term them) have different expectations -- the former says "it works for me, it'll work for you if you do *this thing*, put up or shut up", while the latter says "it works only by accident, it's broken *here*, *here*, and *here*, and the fix is *thus and such*".

 

Anyway. That's my last word on the subject, unless someone wants to discuss a HDX board redesign via PM. No hard feelings on my side; I'm just vocal and passionate about engineering.

Link to comment
Share on other sites

Thanks for that it will make it easy to back up disks to a pi or other cheap box.

 

What i don't understand is the hostility in your posts. Perhaps you can explain why you are so negative rather than constructive. The ti community is small and we all work together to better the machine.

 

I'm sure Fred would respond positively to any constructive comments to his free server and dsr he developed.

 

If you are willing to work out a better solution we are all happy to test and try anything.

 

To me the best part of hdx it's that it's a DSR. That makes it very easy to use.

 

The server could be improved as you state it is not without issues for some more than others.

 

I'd really like to see the ability to use a disk manager on the ti to open disk images on the pc like you open a subdir.. Similar to the way tidir would on the pc. Copying files to and from the disk image.

 

Anyway i look forward to seeing what else comes of this. And i hope that it's a positive experience for all of us.

 

As for the speed of the xfers the best we have on the stock ti is 19200 and that only works reliably with a very special cable setup and software.

 

Greg

 

Sent from my LG-H811 using Tapatalk

Link to comment
Share on other sites

(okay, *one* more response. Selective response.)

 

Thanks for that it will make it easy to back up disks to a pi or other cheap box.

No worries. I forgot to attach a disclaimer to the code, but it's public domain. Feel free to extend it to meet your needs.

 

What i don't understand is the hostility in your posts. Perhaps you can explain why you are so negative rather than constructive. The ti community is small and we all work together to better the machine.

Right, a lot of context is lost. You can't see my body language, you can only read the words and imagine my facial expression, body language, and tone.

 

As I said in my reply to Omega, engineers look at things from a different perspective than would a user. If you re-read my first post, I was reporting my (ultimately successful) attempt to get the HDX working, what I had to do in order to do so, the design and implementation issues I noticed that prevented the HDX from working in many cases, and summarized that I didn't think the end result was worth the effort. In my very first sentence: "My mileage varied".

 

Negative bug reports are as important as, if not more important than, neutral or positive bug reports. With a (properly written) negative bug report, problems are identified and hopefully solved. At the very least, it helps the next person who Googles the HDX problem they're having.

 

And that's what I did. I do admit that your sentence about the protocol criticism made me a tad angry, and that shaded the tone of the rest of my message, but that shade was a wry "oh, you think I'm just armchair-general'ing this? Please allow me to show you my research and a sample implementation, sir".

 

I'm sure Fred would respond positively to any constructive comments to his free server and dsr he developed.

The best thing Fred could do would be to open up the source to his DSR and the Windows application, or at least make the protocol documentation match the behavior.

 

If you are willing to work out a better solution we are all happy to test and try anything.

Well, the hardware looks like it needs the most attention at this point. The single RAM chip needs to be split into an EPROM and a very small bit of RAM, plus a bit of logic to toggle CS on the RAM when an I/O operation happens. The battery circuit would be removed entirely. That eliminates the need to cut the interrupt line right there, with the switch that goes along with it.

 

That raises the question: who bells the cat? I don't need nor want the HDX; I installed it at the recommendation of Omega, and it didn't solve any problem that I needed solved. I could redesign the board, but again that would be time and effort expended on a project that I would not use because the HxC better fits my needs than does the HDX.

 

On the software front: you've seen my quick stab at a better solution. I can expand that to encompass the rest of the protocol (and that's the exception to the above statement: Fred's Windows application needs replaced, and that I'll gladly do), but that will take time as I have to watch the serial port with the equivalent of a logic analyzer to see what it's *really* doing. (I'm assuming that Fred would have updated the available documentation if it existed)

 

In summary, I wrote what I did to document the gyrations I took to get the HDX to work, what I discovered along the way, and my conclusion about the worth of the HDX. It's negative because my experience was negative; a non-engineer given the same hardware would not have been able to work through, even with the help of the AtariAge community, because the design is only about 80% working.

 

Again, there are no hard feelings on my side. I would like it if folks keep in mind that when I say something about hardware, software, and protocols ... that I've done my homework and respectfully request that my words be taken seriously. However, I'm a relative newcomer to the forum, and if my signal-to-noise ratio is judged to be too low, then do let me know and I'll withdraw from this forum. There's precedent for that icon_smile.gif

 

Cheers,

 

-- Chris

  • Like 1
Link to comment
Share on other sites

I definitely appreciate your input, Chris--so please don't disappear on us. I understand the engineer mindset of testing things to destruction. I do it myself--and I'm glad to see a dedicated engineer here! Your insights will help a lot of different projects become a lot better than they were before you set eyeballs on them. Mangle any of my designs as appropriate (and let me know of potential improvements). I'll definitely use the input! :)

Link to comment
Share on other sites

I definitely appreciate your input, Chris--so please don't disappear on us. I understand the engineer mindset of testing things to destruction. I do it myself--and I'm glad to see a dedicated engineer here! Your insights will help a lot of different projects become a lot better than they were before you set eyeballs on them. Mangle any of my designs as appropriate (and let me know of potential improvements). I'll definitely use the input! icon_smile.gif

*chuckle* Thanks for that.

 

Honestly, your designs are extremely clean. I remember looking at your UberGROM and being impressed that you'd brought out the in-circuit programming lines to a header -- and put them in the right order. At my previous gig, we had to have Foxconn build a new test fixture for *every* *single* *project* because none of the design teams could come up with an on-board JTAG interface that everyone liked. You did it right, and I appreciated the beauty of the simplicity of the design.

 

(off-board JTAG on our gear was a different story, but I think that will be under NDA until the heat-death of the universe)

Link to comment
Share on other sites

(okay, *one* more response. Selective response.)

 

 

No worries. I forgot to attach a disclaimer to the code, but it's public domain. Feel free to extend it to meet your needs.

 

 

Right, a lot of context is lost. You can't see my body language, you can only read the words and imagine my facial expression, body language, and tone.

 

As I said in my reply to Omega, engineers look at things from a different perspective than would a user. If you re-read my first post, I was reporting my (ultimately successful) attempt to get the HDX working, what I had to do in order to do so, the design and implementation issues I noticed that prevented the HDX from working in many cases, and summarized that I didn't think the end result was worth the effort. In my very first sentence: "My mileage varied".

 

Negative bug reports are as important as, if not more important than, neutral or positive bug reports. With a (properly written) negative bug report, problems are identified and hopefully solved. At the very least, it helps the next person who Googles the HDX problem they're having.

 

And that's what I did. I do admit that your sentence about the protocol criticism made me a tad angry, and that shaded the tone of the rest of my message, but that shade was a wry "oh, you think I'm just armchair-general'ing this? Please allow me to show you my research and a sample implementation, sir".

 

 

The best thing Fred could do would be to open up the source to his DSR and the Windows application, or at least make the protocol documentation match the behavior.

 

 

Well, the hardware looks like it needs the most attention at this point. The single RAM chip needs to be split into an EPROM and a very small bit of RAM, plus a bit of logic to toggle CS on the RAM when an I/O operation happens. The battery circuit would be removed entirely. That eliminates the need to cut the interrupt line right there, with the switch that goes along with it.

 

That raises the question: who bells the cat? I don't need nor want the HDX; I installed it at the recommendation of Omega, and it didn't solve any problem that I needed solved. I could redesign the board, but again that would be time and effort expended on a project that I would not use because the HxC better fits my needs than does the HDX.

 

On the software front: you've seen my quick stab at a better solution. I can expand that to encompass the rest of the protocol (and that's the exception to the above statement: Fred's Windows application needs replaced, and that I'll gladly do), but that will take time as I have to watch the serial port with the equivalent of a logic analyzer to see what it's *really* doing. (I'm assuming that Fred would have updated the available documentation if it existed)

 

In summary, I wrote what I did to document the gyrations I took to get the HDX to work, what I discovered along the way, and my conclusion about the worth of the HDX. It's negative because my experience was negative; a non-engineer given the same hardware would not have been able to work through, even with the help of the AtariAge community, because the design is only about 80% working.

 

Again, there are no hard feelings on my side. I would like it if folks keep in mind that when I say something about hardware, software, and protocols ... that I've done my homework and respectfully request that my words be taken seriously. However, I'm a relative newcomer to the forum, and if my signal-to-noise ratio is judged to be too low, then do let me know and I'll withdraw from this forum. There's precedent for that icon_smile.gif

 

Cheers,

 

-- Chris

 

Further discussion on the HDX's expansion possible replacements and it's protocols really should be in the development sub-forum. I personally look forward to the discussion and perhaps Fred will join us, as he's a member here as well.

 

Oh and also the HDX protocol also works via cfhdxs software on the nanopeb (both versions the 9902 and 16550) and the TI and corcomp cards (so far haven't got a Myarc card to test) with just a straight through cable on rs232/1 or a null modem on the nano..

 

Greg

Link to comment
Share on other sites

(okay, *one* more response. Selective response.)

 

 

No worries. I forgot to attach a disclaimer to the code, but it's public domain. Feel free to extend it to meet your needs.

 

 

Right, a lot of context is lost. You can't see my body language, you can only read the words and imagine my facial expression, body language, and tone.

 

As I said in my reply to Omega, engineers look at things from a different perspective than would a user. If you re-read my first post, I was reporting my (ultimately successful) attempt to get the HDX working, what I had to do in order to do so, the design and implementation issues I noticed that prevented the HDX from working in many cases, and summarized that I didn't think the end result was worth the effort. In my very first sentence: "My mileage varied".

 

Negative bug reports are as important as, if not more important than, neutral or positive bug reports. With a (properly written) negative bug report, problems are identified and hopefully solved. At the very least, it helps the next person who Googles the HDX problem they're having.

 

And that's what I did. I do admit that your sentence about the protocol criticism made me a tad angry, and that shaded the tone of the rest of my message, but that shade was a wry "oh, you think I'm just armchair-general'ing this? Please allow me to show you my research and a sample implementation, sir".

 

 

The best thing Fred could do would be to open up the source to his DSR and the Windows application, or at least make the protocol documentation match the behavior.

 

 

Well, the hardware looks like it needs the most attention at this point. The single RAM chip needs to be split into an EPROM and a very small bit of RAM, plus a bit of logic to toggle CS on the RAM when an I/O operation happens. The battery circuit would be removed entirely. That eliminates the need to cut the interrupt line right there, with the switch that goes along with it.

 

That raises the question: who bells the cat? I don't need nor want the HDX; I installed it at the recommendation of Omega, and it didn't solve any problem that I needed solved. I could redesign the board, but again that would be time and effort expended on a project that I would not use because the HxC better fits my needs than does the HDX.

 

On the software front: you've seen my quick stab at a better solution. I can expand that to encompass the rest of the protocol (and that's the exception to the above statement: Fred's Windows application needs replaced, and that I'll gladly do), but that will take time as I have to watch the serial port with the equivalent of a logic analyzer to see what it's *really* doing. (I'm assuming that Fred would have updated the available documentation if it existed)

 

In summary, I wrote what I did to document the gyrations I took to get the HDX to work, what I discovered along the way, and my conclusion about the worth of the HDX. It's negative because my experience was negative; a non-engineer given the same hardware would not have been able to work through, even with the help of the AtariAge community, because the design is only about 80% working.

 

Again, there are no hard feelings on my side. I would like it if folks keep in mind that when I say something about hardware, software, and protocols ... that I've done my homework and respectfully request that my words be taken seriously. However, I'm a relative newcomer to the forum, and if my signal-to-noise ratio is judged to be too low, then do let me know and I'll withdraw from this forum. There's precedent for that icon_smile.gif

 

Cheers,

 

-- Chris

Chris, I'm not an electrical engineer or barely an apprentice for that matter, but I am a 10 year machinist as well as a mechanic and I taught myself to design in AutoCad, and do like good engineering, so I do like your input. Please don't go away! Thanks

Link to comment
Share on other sites

(I dislike quoting entire posts, so I've taken the liberty of snipping your response a bit. I hope you don't mind.

 

We'll have to agree to disagree on this.

 

I don't mind a bit, I do it all the time.

 

We actually don't disagree on everything on this topic (I'll post in your new thread). I'm pleased to see that you are one of those individuals who understands that people can disagree on some things, and still get along, unlike some presidential candidates. :)

Link to comment
Share on other sites

  • 3 weeks later...

I have updated the Atarisoft multicart to include all the titles.

 

post-35226-0-71295100-1456664680_thumb.png

 

The cart works on a unexpanded console without the 32K. It is a 256K non-inverted image that can be doubled to work on a 512K EPROM (both versions attached). It needs a board that starts up in the first or the last bank in order to see the menu. Soft resetting will not reset the bank, so you need to press a reset button or power cycle to get back to the menu. Perhaps someone with knowledge of GPL can make a version for the Ubergrom cart that doesn't have these issues? Edit: See below.

 

For the menu I have used a modified version Tursi's Multimenu where I have changed the graphics and reversed the order of searching to fit a non-inverted cart.

 

Each 16K game has been hacked to change the ROM bank numbers. For Pac-Man and Ms Pac-Man this was particularly challenging because the ROM words used to change the bank (>6068, >646C) are also used to select sprite patterns of the ghosts when they are blue/escaping (>68 or >6C). So when I changed these words the blue ghosts showed up as random patterns. The solution was to add some code that uploaded the patterns to the right place in VDP RAM, but there was only one available location that also selected the right ROM bank so the blue ghosts are no longer animated.

 

I haven't had time for careful testing, and I haven't tried it one hardware yet, so it's possible that some games crash later on. Please report any problems you find.

 

Enjoy!

 

17 March 2016: Added a GROM file that, when added to an UberGROM cart using GROMCFG, should fix the issue of starting up in the right bank after a soft reset. The GROM contains a tiny startup routine that selects the first bank by writing to >6000.

 

20 March 2016: Attached a disk image with GROMCFG and the GROM file (STARTUPG).

atarisoft8.bin

atarisoft512K8.bin

atarisoft-multicart-source.zip

startupg.bin

GROMCFG.dsk

  • Like 10
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...