jedimatt42

Nice. The only documentation I've found on CYA indicated it is licensed software, not freely distributed. Has that changed? And from that documentation I had made the assumption CYA only displayed this info for HFDC. Is the latest version of CYA that can do this, the one distributed in the Mdos650.ark on whtech?

Is that something that can be set by CYA as well? so that loading the AUTOEXEC will work? [email protected]

The answer to the original question in the topic title, is NO. SYSTEM/SYS can be loaded off of 80 track disk in 80 track drive on TIFDC with 80 track DSR. But once SYSTEM/SYS is loaded, the DSR is ignored, and AUTOEXEC and any other file won't reliably be read.

Oh, I found the menu for the thing that sets it to English. So, that exists...

How wonderful. I found that thread... It just ends... Well the board wasn't that expensive... The menu on it is in chinese. completely. comes with zero docs. I'll have to google around for the menu docs, because there are many things in there that can be fine-tuned, but without a translation, and some divine understanding of RGB, I'm not going to rosetta stone that menu. I pulled out the yellow wire that comes with it's little video signal wire harness. As somewhere I heard tale that the grey wire was csync. Given the Geneve has RGBs output, that seemed correct. I wired up an 8pin din per the link I reference above. I didn't touch the jumper on the Geneve, hoping it was already in 'RED' mode instead of ground mode. I haven't found documentation on which position is which. I have read that it is finicky with the power source... I've tried a couple 5v sources, but they won't sustain the board, it doesn't actually power up. So then I found a 12v source. And that turned it on... Everyone says 5v works best for this thing, so I'll have to find a proper 2amp 5v supply and try that. Here is what I did, and what it looks like: https://goo.gl/photos/Z4KdoJzjpCSNLsmS7 The sync signal seems to be too weak for the GBS8200 to follow. Does anyone know what the Geneve docs mean by saying that the csync is TTL? Does that mean it is only 5v, where normal RGB might be something more? There was some other annotation somewhere that indicated the RGB lines are up to 8v. ???

Has anyone connected a Geneve 9640 to a VGA display using something like or exactly this: http://www.amazon.com/gp/product/B00W3460UU?psc=1&redirect=true&ref_=oh_aui_detailpage_o01_s00 I've got the following documentation link for the 8pin din video port: ftp://ftp.whtech.com/Geneve/schematics/Genever_Monitor_8CM515_pinouts.jpeg Any gotchas? Hopefully this is tonights project.

Success: On whtech, to get a good set of the GPL files ( without the Tony menu and color mods ) I had to build it up from the full set in the Mdos211.ark, and then the latest 'GPL' file in the MDOS650.ark/dsk. Progress... Now a hardware question: Which RAM ( DRAM or SRAM ) on board the geneve is used when the genmod 'timode' switch is off? Cause that memory seems to be bad. And, a history question: where did the swan go? was there not enough room in the boot rom anymore? [email protected]

So, the MDOS/Geneve OS 6.50 redistribution disk only comes with a single file: GPL. There are multiple copies of the complete set on that mdos_gpl_util.hd image on whtech, I assume that was so there was less typing. I'll go try one of those now.

This link belongs in this thread: http://www.ti99.com/geneve/ 384k upgrade details turbo VDP upgrade details 192k VDP ram upgrade details Mouse replacement details [email protected]

Cool, great to see more detail showing up there. The line too long issue was resolved by using a 40track image in the gotek drive instead of an 80 track image. It seems as though the Geneve OS doesn't use the DSR, but the boot rom does. who would have guessed that chkdsk shows memory My chkdsk output is ... 1777664 bytes of total memory 1581056 bytes of free If I have TIMODE in the AUTOEXEC, then the free memory is lower as expected: 1376256 I didn't expect running INITGPL to free TIMODE... after running it the free memory goes back up to the 1.5 meg value. Are there any resources on the PFM mod? Since I don't expect to see a hard drive controller any time soon, it might be the best usability option for booting. Anyway, I'm still looking for info on how INITGPL and EXEC are supposed to be used. Or even a normal GPL file set. I think all the files anyone needs are in that harddrive image mdos_gpl_util.hd... I'll go back to starting with a normal GPL file set, now that I think I've got the 40 track drive issue resolved understood. [email protected]

So, I've now got a Geneve, that I've been able to boot off my gotek drive on my TIFDC w/80 track mod. The OS boots off of my DSSD80 HFE, created by converting a sector image created from TiImageTool with the 'install geneve os' utility menu item. 1st strange thing: The AUTOEXEC created by TiImageTool fails with an error about 'line too long' I hadn't been able to import any sort of text -> D/V80 through TiImageTool that did anything different. But, over on the real box, I can write a new AUTOEXEC with COPY CON AUTOEXEC and that saves properly. So, odd, but not a blocker, unless it is symptomatic of a greater issue. 2nd real issue: I'm a Geneve Newb. MDOS is now Geneve OS. v6.50 distribute disk comes with a GPL that is only one file, there are things on the whtech sight in the mdos_gpl_util.hd that I've been trying to look at and figure out, but I'm not sure what all these parts are. EXEC ? Looking at how it is used in the AUTOEXEC, I'm guessing it loads a EA5 program in GPL mode directly. INITGPL ? I found something saying it makes GPL resident, and makes GPL a built in command? Does this require a modified SYSTEM/SYS? CYA ? Modifies SYSTEM/SYS??? but to what end? 3rd real issue: I can't get anything to load after the OS. Looking at the hd image, I grabbed the MEMTEST, MEMTESU, MEMTESV files, dropped them on the boot disk using TiImageTool, recreated the HFE, and when I run A:\MEMTEST or MEMTEST I just get back "Bad command or filename." I get the same thing with GPL, and CRACK128. This is a genmod geneve with a memex card. When I flip the TIMODE off switch, the Geneve just complains about bad cpu ram found. So I'm guessing the memex isn't working correctly. There does not appear to be any other memory mod made to the 9640. The memex is fully populated. But I haven't found any documentation for the memex board itself to know if the dipswitch bank is set correctly. Anyone have any docs on the memex board? Is the failure to load files a problem with Geneve OS and my 80 track TIFDC? Is there any kind of SystemInfo tool? The change logs for MDOS/Geneve OS indicate the requirement for more memory than the stock 512k on the board... I saw no piggybacked sram. How does the OS fail when there is not the requisite memory addendum? Any help would be awesome [email protected]

Looks like he cancelled the original auction, and it has relisted with shipping as an option... smart. [email protected]

Looks great... XB was a requirement as well, as I recall... In case you want to be precise with that requirements list.

That's good to know, that would be very mysterious behavior to casually observe. I only have 80 track drives for real iron, so I had never tried to work with a 40 track disk in there before, but with emulation and .dsk files flying around, it would be easy to make that mistake. Thanks!

This behavior is fascinating, terrible, awesome, unimaginable, horrifying, insane... There are some parts where I think the owner of the dash-cam was seeking the opportunity for the 'accident' and then most of it is just a complete lack of prudence... This reminds me that when I bicycle through an alien rich community every night, the drivers are obviously confused by my hand signals. I'm thinking I should get bicycle signal lights for Christmas... That video is so long, and there is a clear theme to the cause of those accidents. It gives the impression chaos as the norm in that region. But surely, that is not case? [email protected]

The AT49F040 is the 512k eeprom you can program with your programmer using the adapter that fits, I think it is a 32pin dip adapter. Set the programmer to that chip type, and load the .bin image in this post: http://atariage.com/forums/topic/245962-cortex-basic-in-80-column/page-2?do=findComment&comment=3376824 into your programmer, and program it. --- Ω --- had a blog post that describes how he got started with the same cartridge board and chip. http://atariage.com/forums/blog/567/entry-12391-making-ones-own-cartridges-under-revision/

Oh! I get it! I wasn't controlling the drive type for the emulation. Cool! On this US Thanksgiving holiday, I am thankful that the internet is international, and that I don't have to go to work tomorrow so I can play with this! I saw in the OSD options with the hfdc the drive type, but it only seemed to be empty or 525dd. And no similar option on the TIFDC. I will update my mame install and take another look! Thanks.

So, I'm goofing around with the Geneve emulation in mame. And as I am want to do, I like to set up minimum system, and a maximum fantasy system, and something close to devices I actually have or believe to be eventually obtainable (seriously subjective criteria ) I have been able to get mame Geneve emulation to boot from a TIFDC using a double sided single density DSSD 40 track image. But it fails to read a DSSD 80 track image. Is that a limitation of the Geneve boot rom? or is it a limitation of the mame emulation (maybe cause it doesn't have the 80track DSR image for the TIFDC)? Does a real Geneve use the hardware's DSR rom to boot? Would it ignore the 80 track state of a modified TIFDC and still boot a 40 track image?

That cartridge label looks real nice! So, how compatible is this basic with software for the cortex computer? Was there a document on the port to the 4A?

I of course then wonder, is it time for the battle of the basics ? Just kidding... But I can't resist doing a little computation test... For Cortex Basic computing primes from 1 to 100 with my non-optimized implementation takes 1 minute and 56 seconds. 80 REM TAKES 1:56 ON 4A 90 PRINT 1 100 FOR I=2 TO 100 105 P=0 110 FOR J=2 TO (I-1) 111 D=I/J 112 E=INT[I/J] 120 IF D=E THEN P=1 130 NEXT J 135 IF P=0 THEN PRINT I 140 NEXT I For extended basic (using xb2.7) basically the same code took 2 minutes and 31 seconds 100 REM TAKES 2:31 IN XB ON 4A 110 PRINT 1 120 FOR I=2 TO 100 130 P=0 140 FOR J=2 TO (I-1) 150 D=I/J 160 E=INT(I/J) 170 IF D=E THEN P=1 180 NEXT J 190 IF P=0 THEN PRINT I 200 NEXT I

Ok, this worked for me on my red board. Attached is a 512k image that I've created that as long as your ubergrom doesn't boot into bank 2,3 or 4, it should work. I've padded the trailing 60 banks with bank 1 of the cortex 040 image that Stuart posted. CBASIC80_040_512k.zip What I did to create this image was just some unix-fu. first I renamed the JS99... file that was padded to 32k to something I could type... CBASIC80.bin don't confuse that with the other CBASIC80.bin's in Stuarts original zip... Then... # copy the first 8k to a separate file dd if=CBASIC80.bin of=bank1.bin bs=8192 count=1 # 'fill' the 1st 4 banks with the original bits (just copying the file) cp CBASIC80.bin CBASIC80_040.bin # pad the remaining 60 banks (512k/8k == 64; 64 - 4 == 60) for i in {1..60}; do cat bank1.bin >>CBASIC80_040.bin ; done

If you are putting it in a bigger rom, such as the ubergrom flash chip, and the last bank is where your board boots to on start, you should have luck by copying the first 8k bank into the last bank in the 512k eeprom on the ubergrom, or red board. The rom menu entry will be found by the TI, and the code should run fine, switching into the first banks as necessary. I seem to recall reading that the xb2.7 cart had GPL in Grom as a start up routine to force the bank switch back to the first bank. But without Grom you are at the mercy of the power on state of the bank switching logic chip. Correct me if I'm wrong. So copying the first bank to the boot bank is an easy workaround that only requires some file splitting.

I recently put in a 12v fan in the PEB following the instructions on mainbyte. I'm not sure why they don't have you just use a wiretap connector and take from the 12v lines to the floppy bay. It looks like you've done the math on how much power the fan uses, and concluded you'll be fine. Somewhere else here, someone commented that the drive motors are never both active at the same time, making the multi-drive power concern generally unwarranted. And then solid state drives like the Lotharek or Gotek units, just aren't going to be drawing as much as an old full-height TI 5-1/4" drive. I'm not anything like an expert here, but I had the same impression regarding expansion cards and their power source not being the 12v used for the drives. I seem to remember there were 4 power levels available in the PEB, and most cards have a regulator to get the >5v source down to 5v. Cards like the RS232 may have a different signal level on the external interface, and so they grab one of the higher lines and bring it down... So I had the impression that if a card wanted 12v, it took the ?16v? source and used a regulator for it. And I know a million years ago, we (the folks on the Kitsap peninsula) never did any PEB power modding to run multiple 1/2 height 5-1/4" drives. But for reasons I no longer remember, we always ran TEAC drives. My answers are mostly conjecture, I'd love to hear some facts as well...

The gameplay is nice. The sound of the maze being drawn in the original a-maze-ing is something I deeply associate to the game, and would have liked to see/hear included. Running from the smart cats is cool... the 'scared' behavior works well. Given your original target audience, this looks like a real success. [email protected]

Nice! I didn't realize DISPLAT AT would wrap text. This just goes to show how important context is to deciding how to make something compact. Pretty cool! Ship it! [email protected]