Jump to content

ckoba

Banned
  • Content Count

    271
  • Joined

  • Last visited

Posts posted by ckoba


  1. (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.


  2.  

    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


  3. 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.


  4. Guys, I remember writing this! Stumbled upon this forum by accident. What do you want to know... icon_winking.gif

     

    When I first started experimenting with the CRU inputs to read "the beeps from the cassette tape", I figured the format for basicode out at some point. It's pretty straightforward, with two frequencies, startbit, stopbit etc. I then applied the very same knowledge to create AFSK telex decoder, ZX-Spectrum loader, and turbo loader for the 4A. The latter was just the basicode format with less delay.

    Oh, how very nice to have the original author available for consultation icon_smile.gif

     

    Is the TI fastloader compliant with the protocol as described in http://www.brutaldeluxe.fr/projects/cassettes/bbc/k7_bbc_thechipshop_manual_ocr.pdf ?

     

    The loader portion expects to run from BASIC and controls the tape motor to start playback, yes? What is the timeout duration until it gives up waiting for data, or will it wait forever?

    • Like 1

  5. "Doctor, it hurts when I do this!"

     

    "Well, then, don't do that. See my secretary for the bill."

     

    I'd pull the Syquest from the Win98 machine and (temporarily) install it into the XP machine. Or I'd boot the Win98 machine with a Linux/FreeBSD live CD, dd copy the Syquest drive into a file image, and transfer that to a machine that can handle virtualized drives.

     

    Depends on how much time and effort you want to put into this. Win98 is dead, dead, DEAD.


  6. 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 ...


  7. 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.


  8. Looks like we will need to employ the buddy system while we are there. Nobody 'split up' cause you know how that turns out in the movies. And if you cannot see I-5, go back to where you can see I-5.

    Sound advice. Jesting aside, it's really easy to get lost on the roads in the hills bordering I-5. Once you enter Napavine, good luck finding a way out that doesn't involve a helicopter.

     

    Of course, most of the worst has probably subsided now that ckoba has given up his hunting ground. icon_smile.gif

    I wasn't the hunter; I would have been the prey. Lots of kids "ran away from home" back then, never to be heard from again. And the local cops weren't interested in following up. I could write a small book on the "mysterious dead and disappeared" of Lewis County.

     

    No, sir, on my seventeenth birthday I was sworn into the Navy and off to RTC.

     

    (disclaimer: one of my sisters is among the "mysterious dead". I have difficulty remaining objective where Lewis County, its law enforcement, and its denizens are concerned)


  9. On the subject of starting the cartridge menu from the GROM side of things ... I'm ambivalent.

    Upon reflection, I'm not ambivalent. I like it. It takes the non-deterministic-between-prod-run '378 powerup behavior out of the equation entirely.

     

    One request: please don't deprecate the standalone (ROM-based) multimenu in favor of this. On the off chance that we manage to pack a cart with 15 valid GROM slots, we'd need the menu to be AA01 because we'd be full up on GROM ...


  10. I really like your trick for avoiding the bases issue (simply ignoring the first two bases), but it should be safe to drop this header GROM in just for the sake of the menu. It also requires a patched multimenu that doesn't ALSO have a header, of course. But with this method no matter the reset, the multicart menu will be guaranteed to re-appear. You don't need to duplicate the menu, either, it just needs to be in the bank toggled by >6000 (which is the first bank on the 512k/378 carts).

    Oh, thanks for that. It seemed the obviously right thing to do -- if the TI module scanner isn't handling the bases correctly, it's better to just use the multicart menu. There's more available bases than there are slots, after all, so it's not as if we were going to run out of bases.

     

    On the subject of starting the cartridge menu from the GROM side of things ... I'm ambivalent. It might solve an issue I'm seeing now with TEII, where the loader's scanner is getting confused by a couple of AA01s in cart space that don't have real headers. I'll give it a shot and report results when I'm done.

     

    While I'm at it ... may I re-open a bug report? I still have that problem where I'm seeing the hold-space-for-recovery data in the viewer for GROM slots 0 through, oh, seven or eight I think.

     

    I'm sort of a stickler for building these carts the old-fashioned way, so my method is to prep the Atmel via the TL866, have an (emulated) floppy with the 8k GROM images ready, then insert the cartridge with the space bar held down. Hit "3" to run GROMCFG and we're good to go ...

     

    ... except the (expletive deleted) viewer for the lower slots keeps showing the data for the Atmel recovery bootstrap. Obviously loading images into the viewer, and burning them thereby, works just fine -- but I'm doing it blind, because the viewer continues to show the recovery bootloader code for that slot.

     

    You won't see this in classic99, because you're never going to invoke the recovery. It's only on real hardware that this happens. And hopefully it isn't just me icon_smile.gif

     

    Would this be classified as a "works as intended", "can't fix", or "fixable bug"?


  11. Ok. So it can be connected to speech expansion then. Would be nice if it had some case.

    You really should have a look around this forum on a browser -- Tapatalk is IMO junk.

     

    A guy here put together a 3D printed case about a month ago. No, I won't provide a link -- search the forum with likely keywords using a real web browser, and be enlightened thereby.

    • Like 1

  12. Centralia is better off than in years past and is in fact growing. Chehalis is still kind of run down and like any place has it's share of poor and crime, but there are no more accents and no more Wobbly influence like in the early 20th century.

    Centralia was mortally wounded when Weyerhauser pulled out (putting about half of my friends' parents out of work). When (whatever entity now owns the Steam Plant -- was PacifiCorp back in the day) bought out WIDCO and nuked operations (and put the rest of my friends' parents out of work), Centralia was finished.

     

    I understand that there's a flourishing rash of factory outlets around the Harrison street exit, and most of downtown has been taken over by antique stores. The local mom-and-pop places like Thurmans, Yard Birds, and suchlike were decapitated by (what I've been told is) the only Walmart you can see from low-Earth orbit.

     

    I went to school with the grandkids of *both* sides of the Wobbly unpleasantness. One of the Legionnaires' kids got into DeMolay and told a story about mementos kept in the Masonic lodge from the raid, and the Bland kids (to mention just one of the Wobbly families) were at constant war with the Stewart/Osborne clan (the "concerned businessmen" that gave the Legionnaires their marching orders)

     

    Edit: for the record, I side with the Wobblies. Rule of law never really applied in Centralia; the place was run both in a political and a business sense up through the eighties by five or six families. Dark things happened there, and were covered up as a matter of course. Only in Centralia could the 1919 incident occur.

     

    I don't think things have changed that much. Outwardly, maybe, but that crap from 1919 will always be seething beneath the surface. It's like Stephen King's "IT" without the monster.

     

    The rest of you folks, don't worry, it'll be daylight during the meeting and since the Werewolves don't come out till dark you'll be fine Oh, and if you wanted to get off the freeway and drive through Centralia on your way down to go to the outlet malls, there is plenty of concrete now.

    As with most of the I-5 corridor south of Tumwater, you're fine as long as you stay within about a half-mile of the interstate. Quoting a very-out-and-proud colleague who was telling me about a road trip he took, wherein he had to stop in Centralia to change a tire: "I realized that they kill people like me in places like this". He wasn't aware that I grew up there until after he said that.

     

    Anyway, end pointless rant. You folks will have fun. Just don't stay icon_smile.gif

    • Like 2

  13. it also has the beginnings of patches for RPI and Plato both.

    It looks like you nailed all of the glitches in RPI -- I performed the walkthrough at http://videogamehouse.net/gamemain/cartsnr/rpiratesisle/solution.txt a little while ago and there were no glitches whatsoever. Save and restore were also tested with no issues.

     

    I already had Plato pretty much ready to go (those autostart cartridges are nasty until one learns how to turn them back without messing about at >7800), and it's passed a basic test of the German course.

     

    Attached are modified binaries, along with python patch scripts that will relocate the binaries to any combination of GROM and ROM banks for use in a multicart. These scripts can be run against either the enclosed binaries or the binaries in an RPK.

     

    These can be used in classic99 with the following classic99.ini snippet:

     

    [usercart8]

    name="whacko"

    rom0=8|0000|2000|C:\Program Files\classic99\MODS\multimenu106C.bin

    rom1=8|2000|2000|C:\Program Files\classic99\MODS\phm3122c.bin

    rom2=8|4000|2000|C:\Program Files\classic99\MODS\phm3189c.bin

    rom3=8|7e000|2000|C:\Program Files\classic99\MODS\multimenu106C.bin

    rom4=G2|6000|8000|C:\Program Files\classic99\MODS\phm3122g.bin

    rom5=G3|6000|A000|C:\Program Files\classic99\MODS\phm3189g.bin

     

    (make very certain that the multimenu is in twice, at both the bottom and top of the 512k cart space. classic99 so perfectly emulates the hardware that it has the '378 come up in a random state icon_smile.gif )

     

    I'll be putting together another UberGROM multicart when I find enough GROM+ROM modules to fill up the GROM side of things, but I can cross these two off my list.

     

    Cheers icon_smile.gif

    plato_and_rpi_relocated.zip

    • Like 2

  14. I'd like to know this, too. I would like to replace my wall wart with a scratch-built fused PSU using a multi-tapped transformer, with true earth ground on pin 4, but TI didn't see fit to run a wire on pin 4 (similar to audio-enable on cassette cable) and without that I'm sunk.

     

    A currently-available part number for a female plug with all four pins would be very nice icon_smile.gif


  15. yeah, as I am ♪ far far away ♪ , "Centralia" just sounded a bit like "Valkenvania" to me, a village in a movie.... with Dan Aykroyd, Chevy Chase ?

    Cannot remember exactly, but it was a very funny and strange movie. Maybe it was called different in english.....

    Yeah, that's the right movie with the right actors. Released as "Nothing to Lose" in some countries.

     

    To see how very deeply screwed up Lewis County is, I recommend http://www.lewiscountysirens.com to get a feeling for the local happenings. If what my sisters reported was accurate, the legal system is very much like that in "Valkenvania". Thank god I got out of there before they could pin anything on me icon_smile.gif


  16. .

    ...so if you write a book, just call it "Last Exit: Toledo" icon_smile.gif

    Nah, I didn't get down to Toledo much. Didn't get out of Centralia/Chehalis much, either, because my VW engine ('65 Bug) was perpetually in need of an overhaul.

     

    My ex-wife went to high school there (albeit as an exchange student, doesn't have any Lewis County genes), which colors my perception a bit. You know you're in back-of-beyond when people from Centralia (which was mostly populated by refugees from the Dust Bowl in the '30s -- Centralians have their own accent, for crying out loud) view you as "country bumpkins".

     

    Dammit, now I want to go just to re-experience what a place with no concrete looks like.


  17. just south of centralia off i5

    Oh, god, you're having it in Toledo. The place where nothing happens ... until all of a sudden a kid kills his stepmother, father covers up the crime, and the entire investigation is *completely botched* until a crime writer picks it up fifteen years later. Oh, and the father in question was the principal of the local elementary school.

     

    Lewis County has a lot of dark secrets like that. Medix Wilson (my family doctor) was the country coroner, and I shudder to think how many deaths he mischaracterized.

     

    At least it's not Pe Ell or Vader ... or, god forbid, Chehalis.

     

    Sorry I won't be there. I got out of Lewis County for a reason icon_smile.gif


  18. If you're handy with a soldering iron, there are two separate designs (one 16-bit, one 8-bit) that you can install in your console. The former is at http://www.mainbyte.com/ti99/16bit32k/32kconsole.html... I can't find a link to the latter, but it's here in the forum somewhere. I'm sure someone will chime in with a link within a day.

     

    There's also a fellow that will swap your unexpanded board for an expanded board (8-bit). His thread is at https://atariage.com/forums/topic/236234-32k-consoles-available/

     

    You can also obtain a nanoPEB or CF7 at http://www.stargames.be/shop/105-accessoires... and you'll get either a parallel or a serial port, as well as a CF card emulating floppy disks. The downside is that general consensus says the quality of these aren't as good as they used to be (read: many bad solder joints), and they're sort-of supported by their developer.

     

    My main (non-parts) console runs the 16-bit internal modification, and I am very happy with it. YMMV.

    • Like 2

  19. yes it did. I believe 4 different ones. you can find links to them in the development thread here.

     

    HERE

    Thank you -- I should have looked closer at the pinned "Development tools" topic.

     

    The retroclouds link is dead, by the way. In fact, every retroclouds link I've tried in the past few weeks (months?) has been dead. archive.org has one snapshot of the Pascal disks, so I'm good to go there. (link: https://web.archive.org/web/20130703201423/http://www.retroclouds.de/atariage/devres_UCSD_disk_images.zip )

     

    Now to track down LOGO ...

     

    Edit: found, on theoldcomputer.com. That site requires registration to access files, so to help out the next poor sod who wants to see LOGO on their machine again, I've attached them here.

    TI_LOGO_Sampler_(1981)(Texas_Instruments)PHD_5070req._PHM_3040.zip

    TI_LOGO_Curriculum_Guide_(1982)(Texas_Instruments)PHD_5074.zip

    • Like 1

  20. So I found a P-Code card just laying there by the side of the road (not really, but as good an explanation as any).

     

    Did this thing originally come with floppies? When I enable it, it's probing every drive in the PEB for something (and not finding it).

     

    If it did, could some kind soul send along images or point me towards a place I can download them? Please don't say "search whtech.com" unless it's a direct URL -- I've been doing that, and the closest I can find are two zipfiles (usus and ususvol) that contain plain files).

     

    Extra: same question for TI LOGO and TI LOGO II. I have just finished a multicart that contains them (thanks to Tursi for the multicart loader that handles ROM bankswitching), and I've heard that LOGO II (at least) came with a demo diskette.

     

    Thanks in advance ...


  21. 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


  22. Actually the way I do it is with DSK2PC. I 'upload' the virtual disk (HFE) to my PC. It comes out in my DOAD directory as as a perfect DSK image on the PC.

    One of these days I'll HDX-ify my RS232 card. I have the boards, but need to get a few parts the next time I go into town. I only run emulated Windows (VMWare for the EPROM programmer, Crossover for classic99 and the rest); I suppose I'd need to write a HDX server in C or Python to satisfy my no-Windows-unless-necessary compulsion. Nice that Fred's server implementation has a protocol debug window icon_smile.gif
    • Like 2
×
×
  • Create New...