sup8pdct
-
Content Count
935 -
Joined
-
Last visited
Posts posted by sup8pdct
-
-
already been done. check out older topics
james
-
I think it would be useful to prepare an Indus GT ROM fixed so that:1) we can finally get rid of Synchromesh (which is said only to fix bugs in the highspeed code, that is already there, but does not work)
2) nothing, and especially Indus CP/M, gets broken
Hmmm Let me think about it. Could take 7 1/2 million.....................
The Indus CP/M part will need to be looked at to see what entry points are used, if any.
Have read that there are 2 parts to CP/M. CP/M it self and Hardware extentions.
No idea which is what and quite possibly a loooot of work.
The syncromesh part is self contained with jumps to the firmware where needed.
The Highspeed bitbang SIO is in the addon code. also included is sector maps for the Syncro format which looks exactly like USD format.
Also 1 extra command is added.
Any volunteers to dissemble the indus CP/M?????
James
-
I have disassembled the IndusGT V1.2 rom , the Syncromesh code, the ramCharger code and the loader for both.
I have put some comments to things I have worked out but it still needs work. (very big HINT)
The version Number of the rom is also stored at $CF5 for V1.2.
The SDX version of syncromesh excludes the ramcharger code and some changes are made to the loader as noted
Any comments, please let me know.
Have not checked if it will assemble yet.
James
-
Hi!You need two things:
1) own SIO routines
2) ultra fast music player
While POKEY do the serial transmission only two channels (merged in one 16 bit channel, to give 16-bit precise baud rate generator) are used. Next two channels is free for your use. The system SIO routines is not prepared to work correctly with any music player. But after some changes it is possible to adopt it to co-operation with simple and fast music player.
But in my opinion the best solution is... write own SIO routines. How it works in real world, You can see our old production Overmind. This trackmo have own IRQ loader, and plays music all the time (while loading next parts, music player plays only 2-channel music)
with greetings
Seban/SLIGHT
Here is one way to do it.
This is very much a hack. It copies the osRom (XL) to ram and changes the sio routine to enable the music to play.
It is also a bootable routine.
The music I stole from some educational program and removed the voices that were used for SIO.
Also there is very much a lack of comments, so any questions, I may remember the answer to them
-
This should be easy, but believe or not, I never saw this on the past.I want to load a game into 2 stages:
- First stage load the intro, play a music and wait until you press the START key
- Second stage load the main game. There is no back to the First stage.
I want both stages join on a unique XEX file. What are the structure of the file that should be. Or better still, how it can be do on a MADs assembler environment?
I'll appreciate any help on this topic.
Thanks
I got draconus to load from SDX and 256K ram. I simply broke droconus in to 3 bits and made several stages. First 2 load bits in to memory then hide them to ram under the roms, then load the main bulk of the program, load the bit of code that overwrites dos in lo memory then run.
Very cool loading that game from a harddrive under dos control
Have done that with several games.
James
-
Hey all,Is anyone running this combo? I'm trying to set some stuff up in anticipation of installing the MyIDE next week, and I've run into a problem where I can't get Mac/65 to run under MyDOS; on load, it simply returns to the dos menu. And from the info I've been able to find, Sparta 3.2 is not compatible with the internal MyIDE...which leaves me a little stuck.
Has anyone successfully run Mac/65 under MyDOS, and if so, did you have to do anything to get it to run? I've tried on both real HW and Atari800...
Thanks!
How about posting your version of the file so some of us can look at it and see what is going on?
James
-
My field service manual includes the external data separator at the end of the book with the noted wave forms.I was talking about the FSM that was recently uploaded here, the one that Martin72 downloaded. It doesn't cover the later 810 versions with external data separator.
You obviously have a newer/updated version of the FSM.
Ahhhhh. I sit corrected.
I should point out that my field service manual is by the looks a 2nd (at least) generation photocopy.
There was a lot of that here in australia and most likely in other countries.
Even my old action cart is a copy of an original 2 eprom version.
James
-
I'm guessing that ICD and/or FTE made the switch to a single ROM and changed the banking scheme and nothing more.The single eprom version Black cart with yellow label came from OSS.
I have 4 of those, 1 of each language, tho my Mac65 has been modded to have all 4 languages in the one cart.
They made the improvement/update to save costs I would guess.
James
-
Actually the 1771 does have an integrated data separator. But it is a very simple one, not too reliable. For this reason the 1771 could be configured to optionally, use an external data separtor.My field service manual includes the external data separator at the end of the book with the noted wave forms.
James
-
Hmm, me, TDC and Miker find interesting thing: I have cartridges (release in Poland years ago) with ACTON! module. Original OSS 1983 release had statement on the bottom of screen: "ACTION! ©1983 ACS". I have two other version, where are other statement: "ACTION! ©1986" and "ACTION! ©1987". Both are cartridge version with propertymap for that versions. So, I have a question: anybody hear about this version? There are any differencies with OSS 1983 version?I personally know of 2 cart versions. A 2 eprom and 1 eprom. Both have different switching and I think the lower 4K of the 2 eprom version could be switched off and the ram under it accessed.
As for those versions, Maybe it has something to do with when OSS bought the carts somewhere near 1986?
James
-
I have bought recently a 810 diskdrive. The diskdrive is complete and the case is in good condition. When i connected the drive to my computer the following happens:- the Atari computer recognize there's a drive
- the led on the drive illuminates
- the diskette spins continuous
- the head don't move but once in the let say 10 seconds there's a strange sound audible at the stepmotor (it seems that the drive tries to move the head beyond the maximum (or minimum) position).
I dowloaded the Service manual and i see a difference with this drive. In the socket of A105 of the Side 810 pcb there's another pcb with Atari code CO177227. Do someone know what the meaning is of this pcb? At this PCB there's the FD1771B disk controller at socket A203. Can someone help me with a circuit diagram of this pcb?
I have attached a picture of the 2 pcb's.
That extra board has the floppy controller chip and hardware data separator. The early versions of the floppy chips didn't have built in data separator.
This includes the 1771 as used in the 810 and the 179X series as used in the ATR8000 (any others?). The 279X series as used in the 1050, Indus and the 1770,1772,1773 (XF551) does have a data separator built in and is adjusted with a variable cap (279X series).
The early 810's didn't have the data separator and the floppy controller was plugged directly into that socket.
How does the data separator work? I am not really sure. the 810 field service manual has several wave forms from different sections of the data separator.
That noise you hear is the head banging against a stop to make sure the head is positioned at track zero. It keeps doing that because for some reason, the drive cannot read the disk.
Is the head clean? does your 810 have a top board that the head plugs into? Pulled all plugs and re seated them?
James
-
Indeed it looks like a Happy clone, and a very good one. Not that I've seen too many, but I don't recall seeing a Happy clone that included the connector for the Happy Controller, as this one has.You can't just swap the ROM however. The original Happy had a banked ROM for protection purposes, it included the bank-switch logic internally on the chip. Clones usually use a regular eprom and reproduce the banking behavior with external logic.
Btw, Mathy is of course right. The Duplicator and the Speedy aren't "clones". The Duplicator is almost the same idea, but with a different board, firmware and software. The Speedy, AFAIK, was partially inspired in the Happy, but it is less targeted towards copy protection, and have some other type of features.
Has any one tried to fix an original Happy board with a defective rom?
I had to add 2 (I think) LS chips to emulate the bank switched rom.
A rats nest of wires but at least it worked.
At least 2 of the LS chips on this clone would be used to emulate the bank switched rom.
Finding which 2 is the next challange
James
-
My brother in law is looking for his collection of floppies. Hopefully he'll have either a DOS or a BASIC floppy. I also have more pictures if anybody is curious about what is what in here. From what I can tell, I have spares for the OS, memory and "strange board with potentiometer", plus power boards for the 800 and the floppyIt has been setup as a dos only box.
I noted the 810 drive is a late one with a data separater board and a separate head amplifier board.
I was wondering what that extra board on thew wrong side of the 810 side board was...
The 2nd slot wasn't used for much anyway.
The 800 board is fully populated with all cards.
The spare 800 mother board looks complete. the cards that go in to it from front to back are:
Personality board or rom board. it is the one with the 3 24pin chips and several logic chips.
1st ram slot. This one MUST have ram in it. Atari made 2 sizes, 8K and 16K
2nd ram slot. This one was also used to put extra ram in that was banked switched. this was a 3rd party device made by Axlon
3rd ram slot. There was a 3rd party 80 column board that want into this slot The 2nd slot had to have 32K in it.
Processor slot. 3 40pin chips and a logic chip
The first 4 slots could be accessible under a removable top because when the 800 was first made, Ram was very expensive and could be upgraded as needed.
But as usual, ram price dropped and latter ones were sold with 48K.
The ram card on the spare 800 board has something hanging off of it. could you take a pic of that please?
James
-
I'd like to get one of these, but with the ABBUC member charge, shipping and all it's $310 US!
When I got mine, I opted out of the abbuc membership. got it for slightly cheaper
James
-
Is there anyway to redirect the output of the SpartaDOS 3 TREE command into a text file?? It seems to me that there is but I cannot remember it.Thanks.
I think it is:
Command >>file.txt
at least it is true for SDX.
James
-
Well, as the title implies, today after a couple of years without using it, I found out that the Mitsumi mech of one of my XF551 drives isn't working properly. If I try to boot from it, I get the usual "BOOT ERROR" messages; if I try to read a disk'sThanks in advance.
It could be the mech it self.
From my playing around with things, no all pc 360K drives work. most will need a mod to get it to work and then is a problem of length.
I have found the one used in the XF is short compared with the pc ones I have. They hit the heatsink at the back of the drive and won't fit.
I have no idea about head settle times between different mechs.
James
Hmm. My experience has been exactly the oposite.. Have you been trying 1.2meg HD mechs or something?
"packrat" tendencies...
I should point out that my mechs would be "old" ones they have jumpers for mech 1 to 4 and have a position for a resistor terminator pack.
I got them for use on the BB. 2 are 360K mechs and 1 is a 1.2. I either got them off my mate for nothing or from old pc's, also for nothing.
All are longer.
I used them when I was copying all my floppies to ATR's. If my 1050 wouldn't read a sector, I would then use the mechs and keep swaping round till I got the sector or I gave up.
I didn't opt for the "PC" type. they can be modded but is a PITA.
James
James
-
I also have a PBI experimenters board. It has a decoding chip, 6520 and some dip switches to change the address where the 6520 appears in memoryand a small power supply. it has a proto area and provision for a 25 pin socket.
I have used this to interface to a judging box along with a cart that I programmed.
James
James,
Sounds like the same one I have. Wasn't it made by some company called MicroXL or something. It's been so long since I looked at it. I tried to interface a GI AY-3-8910 programmable sound generator with mine. Never did work out bugs in it. But I still have it in my mess of stuff. It definitely was a neat board for those who wanted to experiement with the PBI connector and build their own PBI devices.
One thing I did build some years later was a Nintendo development board interface. It was based on plans ordered out of Nuts and Volts magazine. The plans were based on a C-64 interface and I adapted it to use the two joystick connectors on the 800XL to communicate with the Nintendo. Other than going as far as building it and getting it to work, I didn't do anything else with it.
Glenn
Glenn.
I dug out mine and took a pic
As you can see, it is a microport xl made by MPP © 1984
Maybe the first available PBI device? tho not a real device as one would call it.
I'm not going to show the underside as it is a rats nest of wires.
The 3 74LS244 chips buffer the 6821 lines to protect the Pia.
The small 8 pin chip, I found in a trs-80 and it drove a reed switch in a coil also from the trs-80.
It broke about 6 years ago and I replaced it with a 5V reed relay in that D31A3100.
The 9 resistors are there to make sure the 9 input lines are pulled to 0v when they are low which is the default state.
power for the board comes in via the 25pin sub D.
It is used to interface to 3 hand pieces and a number display build in the early 70's.
the control program gets the 3 numbers, adds them and displays the result.
The real good bit is the stats also kept by the program for the application this is used for.
I got it from Best electronics
James
-
Well, as the title implies, today after a couple of years without using it, I found out that the Mitsumi mech of one of my XF551 drives isn't working properly. If I try to boot from it, I get the usual "BOOT ERROR" messages; if I try to read a disk's directory on it (using it as D2:, which was how I originally had it - changed it to D1: only to test it alone), I get ERROR- 163 (meaning the drive isn't responding). Any suggestions on where to look? On first sight, I can't see anything suspicious, I'm leaving the multitester testing for tomorrow since it's late already.I've already discarded any electronics problems in the board, swapped the mechs with the other XF551 and found out it's the mech. The motors seem to be OK (drive spins normally and head moves normally too), I also cleaned the head and tried to realign it just in case, no changes. Haven't checked solder points in the mech yet (as I said, it's late already - I'm tired and the artificial lighting isn't good enough either), if anybody knows what the "usual suspects" tend to be, I'd appreciate the help. As I said, I connected my equipment after a 2 year hiatus (more or less), last time it was working fine except for one of the SIO connectors (which I already resoldered today) so overheating and such isn't the issue here...
Thanks in advance.
It could be the mech it self.
From my playing around with things, no all pc 360K drives work. most will need a mod to get it to work and then is a problem of length.
I have found the one used in the XF is short compared with the pc ones I have. They hit the heatsink at the back of the drive and won't fit.
I have no idea about head settle times between different mechs.
James
-
Following on from the various threads relating to MIO and the recent thread about the 400 got me thinking about the above subjectsFirstly relating to the xl’s PBI port…I’m just curious as to whether it’s only ‘single device’ compatible or multi device compatible (assuming that the device originally attached to the PBI port has a pbi connector as well and that the pbi device you want to connect to the first pbi device also has a pbi connector to connect to the first pbi device)
Atari had made several expansion boxes called the 1090XL. it has 5 slots in it and a backplane like a PC. It has it's own power supply and some buffer chips on the PCB.
I got mine from a guy who worked for one of the then harddrive manufactures. Atari sent them a sample for these people to do a harddrive card.
We all know what happened to that project.
The PBI has software support for 8 devices.
only the 600XL has power available on the PBI used for the 1064XL memory expansion.
The cart=eci also has power but it isn't advisable to use it.
I also have a PBI experimenters board. It has a decoding chip, 6520 and some dip switches to change the address where the 6520 appears in memory
and a small power supply. it has a proto area and provision for a 25 pin socket.
I have used this to interface to a judging box along with a cart that I programmed.
James
-
The SIO2USB Team will make a 3rd production run.The price is 135 EURO incl. USB-Stick;
Postage for European Union 20 EURO, for all NonEU Countries 30 EURO (payable via
Paypal)
The preorder can be registered on the webpage
(click on the english flag, then select SIO2USB Preorder)
Preorder will be open until 07/13/2008
If you have any questions about the new production run or how to order, please send an E-Mail to the address given on the preorder page, as the SIO2USB team does not monitor this AtariAge thread.
Have all the problems listed in this thread been addressed in the current version of the firmware?
Thanks,
Fish
They most certainly have been. With my help, those problems have been fixed.
With the latest firmware, more devices now work with it. someone said a USB to SD card adapter works.
personally, the 1GB stick have is large enough
James
-
If your'e using the D5xx scheme...sometimes you still cant' run the dumped cart image...As it will still contain cart protection techniques i.e. esp. if the D5xx is constantly dumping data in the same area of ram...which makes it impossible to not only dump the cartridge but also run itAll D5xx means is that a signal line is pulsed. It's source is a 74LS138 chip that also selects the hardware chips. the destination is the cartridge port. The MMU disables ram access always in the $D000 to $D7FF area, no exceptions.
When you see D5Ex used for selecting banks, it is the hardware of the cart it self that does the decoding.
Unless the cart itself has ram, what you say simply doesn't happen. At present, I know of no game carts that have ram on them. In fact, I know of no carts at all that have ram on them.
James
-
I remember that, way back when an Atari retailer called 'Home Entertainment Centre' in Birmingham (UK) used to import Indus GT's...I heard thaqt they went under and the premises were taken over by another well known Atari retailer 'Software Express'I have had my Indus since 1984 (I think) and while it is built like a tank and a very nice drive, it is nowhere near as versatile as a Happy 1050 or USD 1050... at least not to me.
It's a wounder that noone has written a software add in for the indus to make it work like a USD drive instead of syncromesh. also to make it act like an archiver.
With the ramcharger and a small hardware mod, it could be a bit writer as well. be able to copy anything then
James
-
1
-
-
Great job MrMartian!Is it true that the indus inverts the data from the atari on the sio buss? I am not 100% on this. also is the FDC used in the indus the inverting data type?well done. I have the USD rom disassembled here. want a copy of it?
James.
Nothing is inverted in this drive. AFAIK, the only drive I've seen with the inverted FDC was the 810..
I don't know much about the Indus, but AFAIK no drive inverts the data on the SIO bus (if you mean literally on the bus). What all drives do, is to invert the data on the disk.
The reason is, as I've read, a bug in the original 810 firmware. The 810 uses an FDC with an inverted data bus, so everything sent to the FDC (including both data and commands) must be inverted. It seems they inverted it twice though, once when receiving/transferring the data from/to the computer, and once again when transferring from/to the FDC. The net effect was that the data was written inverted on the disk. The bug was harmless, because it was performed both when reading and when writing.
Disregarding if the history is true or not, the fact is that for compatibility reasons, all Atari drives, including third party ones, write the data inverted on the disk sectors.
As soon as I read this, I thought to my self "Yea Right".
I then decided to check. I did 15 years ago dissemble the USD rom and put a lot of labels on things that I had worked out, not by any means complete, but enough to work out what most bits do.
I discovered that what you say is true. Any read or write to the floppy disk data sectors has a EOR $FF to invert the data.
I am trying to work my way through the Indus rom. boy is it hard but have found a few bits and the hardware registers so that is a start.
Have also done the XF551, but it is much harder to work out.....
James
-
RPM.COM in spartados..I got an "error in read... Aborted" message. Oh, well.
Best way to check it though, is with a calibrated adjustable frequency strobe-light...My problem is getting access to one...
Trouble with dos Rpm checkers is that need to be able to read a sector with out errors to work.....
Also if they don't take into account the Ntsc Pal difference like some early ones do.
James
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Indus GT rom disassembly
in Atari 8-Bit Computers
Posted
Must look for that key combo tho i would have thought that would have been a bit of extra code loaded to the indus when one loaded the terminal program for indus cpm.
Good to know that legal entry is used.
The extra command is $23 '#' for format with hs sector layout just like USD sector layout. Enhanced density hs sector layout isn't supported.
You can see it in the indus code @ 7BCD which jumps to 7BD8 with the sector tables @7D90
james