Date   
Re: Software serial and overclocked 1802's #microboards #system1

cmdrcosmac
 


Allison,
See:

https://www.jameco.com/z/CDP1854AE-INTERSIL-CORPORATION-Programmable-Universal-Asynchronous-Receiver-Transmitter-UART-DIP-40_2290543.html

They may not have many left. You'll need one to run UT71. I ordered some and the worked fine. Marked RCA CDP1854AE RCA Z 745.
-Chuck

Re: Software serial and overclocked 1802's #microboards #system1

ajparent1/kb1gmx
 

That and bitbash and performance in the same sentence is only for 
contrast or a discussion of electrical simplicity.

The 1854s... gotta get a few.

Allison

Re: Software serial and overclocked 1802's #microboards #system1

cmdrcosmac
 


I encountered these issues when trying to speed up IDIOT's serial I/O.
I got to 7200 Bd. with an un-modded IDIOT at 4.91MHz. I wanted to get to
9600 or 19200 Bd. Tried messing around with modded bit-bang serial routines.
big PITA with no noticeable benefit. Finally found that Jameco had a few
CDP1854 UARTS. So Patched IDIOT to talk thru the UART. Got IDIOT working,
Experimented with baud rated and throughput. I got maybe a few percent
faster load times at 9600 with the UART than I did with the bit-banger
at 7200. Plus I had to add a millisecond of inter-character (plus whatever
delay already in the terminal program) to avoid overrun. I concluded that
the limiting factor was CPU throughput, not serial throughput. Note that
with well-crafted code the throughput can be improved. Witness David
Madole's loader.

 4.91 MHz was the fastest I could go with my limited set of oscillators
at hand. My Elf will not run correctly at 9.8304 MHz. I'm running
IDIOT out of a 150-ns. AT28C256. Faster EEPROMS are not as common. That
leaves the hi address latches. The 4042's used in "vintage" designs
are slow. The modern 74HC373 has delays of maybe 1/10 those of the 4042.
 Modern RAM is also much faster than the vintage stuff. Research in this
group suggests that 10 MHz is not unreasonable for the CPU clock, and
IDIOT at 9600 Bd. with  bit-bang serial is plausible.
 
 Takeaway- use fast parts and juice up the clock!
-Chuck

Re: Software serial and overclocked 1802's #microboards #system1

ajparent1/kb1gmx
 

The problem is the 1802 has its limits and then memory has finite speed
so  you can exhaust any one of those before another might quit.

Tweaking the code and someone did that can by some serious speed
when combined with faster clock.  Serious is 9600 and faster!

The problem with that is that still a burst rate and sustained output 
can be very much slower.  An example of this running a EELF
at 4mhz a TB program in ram will still take more than 10 seconds
to spit out 2000 chars (enough to fill a 80x25 screen) at 57600
though hardware UART).  At that point we are processing limited
not bit bashing limited.  That only slightly slower than bitbash at
4800.  Also granted that TB was not a speed wiz, just a compact
integer basic.

Allison

Re: MS2000 MicroDos Development System

ajparent1/kb1gmx
 

Here a tie to the last and 1802...

At one point I decided to do a "smart" floppy card that moved a lot of the physical and 
programmatic parts of a floppy to a independent S100 card.  It ended up with
8085AH1 (6mhz clock, 12 mhz crystal) and faux dma but before I got to that
point, I protoed a 765/1802 system. 

The 1802 proved to be a pain to use, IO for host and FDC ports had to be memory
mapped (no N-lines) and test/debug was awkward.  I got it working but it was really 
awkward to program for the protocol from host to slave and it was slow (at 4mhz)
doing the requested processing (host to slave processing, sector read ahead,
deblocking). .  The 1802 DMA capability did save parts.   At the time pushing
the clock higher (1979 parts) was not considered. 

However at that time I was running  Z80 to 8mhz and multiple CPUs
for performance the PC would not match until 20mhz 286s appeared.
At that time the average XT or clone was 4.77mhz. The average 8086
on S100 or Multibus was 8 or 12mhz.

Anywho that's now I got to there... and why MicroDos is interesting to me
as back when (1981) no one even knew or considered there was an
1802 dos!

Allison

Re: MS2000 MicroDos Development System

ajparent1/kb1gmx
 

Lee,

Yes some of the chipsets are 765 cores but the single density is broken mostly
due to clock and other oddities of the chips.  One of the two sites has a capablility
test program for that I think Daves.

An old 8088 XT class can be handy for that but some of the old FDC cards
were stunted as well.  Some of the cheap FDC cards were limited in ability
(hard wired) for only a few data rates and interface options.  They had real 
765A but the data seperator and write clock generation were stunted.
They should work ok for most 5.25" formats and maybe the slower 3.5"
(700-800k).

The CP/m systems can be all over the map for drives, controllers, and formats.
ITs one of the only OSs that managed early on to divorce the system from 
the hardware via abstraction (BIOS).   One extreme is Northstar and H89 with
hard sector.  My own variant of a system is a NS* crate (s100) as it was a good
system and box with my own softsector 765A based controller with a custom
NEC gate array (glue between FDC and floppy).  That allows all possible
formats and all sizes of drives.  Seems extreme but when I was making it it
seemed like a good idea and it also has DMA.  The Compupro DISK1A was
closet thing to to enter the s100 market and I have a few of those!

Why do that?  All formats soft sector other than a few known odd ones
were desired for flexibility and intersystem communications (sneakerware).
It still serves to this day with 4 drives (two sided half height 8", 40 track 
two sided 5.25 FD55E, two sided 80 track FD55GF, and Sony 3.5" 
(720k and 1.44M).  DMA avoided using PIO (too slow).

The 1973/91 can do that too but its a pain to use and program.  It was popular
but people like Tandy misused and misunderstood it and did things like use
deleted data marks for data marks!  Soroc IQ120 used inverted data as the
part they used without realizing it was the inverted data bus part because
it was more plentiful.

I also run DEC PDP-11s in multiple flavors, MicroVAXs and a PDP-8e or two.
Serious retro-computing continues here.

Allison

Re: MS2000 MicroDos Development System

ajparent1/kb1gmx
 

anything before win98Se is fine.  Se was a hybrid of emerging software
tech as M$ and as such a hot mess.

Win98 was ok.   I still have the full Win3.11 kit with all the stuff needed
to add IP networking rather than the anemic Lanman.  Doesn't hurt I
have a pair of Dell 486SX pizza boxes (486/66 32mb ram, decent
video, PORTS serial and parallel).

Allison

Re: MS2000 MicroDos Development System

Lee Hart
 

cmdrcosmac wrote:
Thank you much! I do have an old Dell PC with XP so I can run DOS in a
window. Hope this works.
Chuck, a coupole other things come to mind on using a PC to created microdos disks:

I have an old 8088 PC that I keep working precisely because it can read/write 5.25" and 3.5" floppy disks. I have several other vintage CP/M computers (IMSAI, Heath, Kaypro), and each has its own usique disk formats.

1. You need a really old PC that actually *has* a uPD765 disk controller chip. It can handle all the other formats (any number of tracks, sectors, sides, single/double density, etc.) Later-model PCs often replaced it with chipsets that only emulated the particular 765 modes used by the PC. These chipsets can't read/write/format many of the other computer's floppy disks.

2. There are special programs for using the 765 in a PC to read/write/format floppies for other systems. The one I'm using is called "22DISK" by Sydex. It is a DOS program that runs on PCs with up to a 486 CPU and up to Windows XT. You should be able to find a copy of it on the sites Allison just posted.

Lee Hart

--
ICEs have the same problem as lightbulbs. Why innovate and make
better ones when the current ones burn out often enough to keep
you in business? -- Hunter Cressall
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com

Re: MS2000 MicroDos Development System

Lee Hart
 

gregory simmons via Groups.Io wrote:
have you ever had the experience where, after disassembling something and
understanding it 95%, you run across the actual source code, and think,
"Oh, so that's why they did such-and-such!"?
Many times!

For example, Tom Pittman's Tiny BASIC frequently set the accumulator to 0 not with "LDI 0" but with a "GHI 7" instruction. Why? When you see his source code, he defined an LDIO macro to do this. The source makes it clear that the high byte of R7 would always be 0. GHI 7 is a single byte, while LDI 0 is 2 bytes -- so every time he used LDIO he saved a byte.

When I see particularly screwy stretches of code, it's usually a sign that the source was written in some high-level language; not assembler. The quirks of the language's compiler show through in the executable code it produces.

For instance, FORTH code tends to have strings of addresses (threaded code). C tends to have unnecessary pushes and pops.

Lee
--
ICEs have the same problem as lightbulbs. Why innovate and make
better ones when the current ones burn out often enough to keep
you in business? -- Hunter Cressall
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com

Re: MS2000 MicroDos Development System

Gregg Levine
 

Hello!
Thank you Allison. Yes, that's what happened after NT was released to
an unsuspecting world. I've been running those, and then XP for a
while. In fact I also have a Dell Dimension here, the system is indeed
running Windows98SE.

To do what we're discussing you would need an even older system running those.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."

On Sat, Dec 7, 2019 at 9:09 PM ajparent1/kb1gmx <kb1gmx@...> wrote:

Um no. With NT and above (that inclodes XP) it may work or not as all
of them were designed to run stuff in semi-isolation and indirectly connected
to physical hardware.

So when I say DOS, I mean DOS 3.3 though 6.22, Windows 3/3.11 and win95
with a maybe on win98 (early).

Most of the later "dos windows" are just flaky enough to not behave
well even though they run doom fine.

Welcome to PC world.

Allison

Re: MS2000 MicroDos Development System

ajparent1/kb1gmx
 

Um no.  With NT and above (that inclodes XP) it may work or not as all
of them were designed to run stuff in semi-isolation and indirectly connected
to physical hardware.

So when I say DOS, I mean DOS 3.3 though 6.22,  Windows 3/3.11 and win95
with a maybe on win98 (early).  

Most of the later "dos windows" are just flaky enough to not behave
well even though they run doom fine.

Welcome to PC world.

Allison

Re: MS2000 MicroDos Development System

cmdrcosmac
 

Thank you much! I do have an old Dell PC with XP so I can run DOS in a window. Hope this works.
-Chuck

Re: MS2000 MicroDos Development System

ajparent1/kb1gmx
 

http://www.classiccmp.org/dunfield/img/index.htm
You may find useful tools for archive and reproduction of the microdos media.

http://www.cpm.z80.de/share.html
http://www.gaby.de/edskinf.htm

While a primary CP/M site the same problems with media are encountered and usually same tools needed.

Hope that helps some...

Re: MS2000 MicroDos Development System

ajparent1/kb1gmx
 

OK,
PC-dos can take explicit values for track and sector and there are tools that
can duplicate most all formats save for a few weird ones that are mostly hard
sector or pff the wall (MFM2 and few very unique).  The reality is if the
Microdos can write it then a PC can as well, both rely on the 765 (and kin).

http://web.csulb.edu/~murdock/format.html

FORMAT d:[/1][/4][/8][/F:(size)] [/N:(sectors)] [/T:(tracks)] [/B|/S][/C]
[/V:(label)] [/Q][/U][/V]

Purpose: Formats a disk to accept DOS files.
Discussion
Formats the disk in the specified drive to accept DOS files, analyzing the entire disk for defects.
Initializes the directory and file allocation tables. Can be used to format both diskettes and fixed disks.

The latter is not an issue as its just junk in special places not the low level media format.

Floppies are formatted (sectors and gaps with markers and all) then initialized to look like a
specific format typically DOS FAT.  FYI DOS fat means a given set of sectors have tables
and directory information in place so dos is happy.  To another operating systems its just
sectors used for other purposes and not harm nor foul.  AS long as the sectors are the
right size and in the right density and correct number per of them per track you likely good..
The troublesome one can be two sided media  as some do track x side on 1-10 and the
other side 1-10 where other do side zero 1-10 and side one 11-20.  You simply have to
know this for Microdos, this is where documentation of sleuthing the microDos code
may be important.

A note unless someone had brain damage the first sector on the media is always 1
not zero.

Hope that helps get you to a starting point.

If you use linux there is a format as well and you can use DD (its a loaded hand grenade tool)
so if that route be very careful with DD,  it has the desired power and can also do great
destruction if aimed at the wrong disk.  Teh most useful function is reading media without 
paying attention to file system, raw copy on a sector, track, or cylinder level.

I use both/either to create formatted blank media for many systems.  By blank I mean has
the formatting for raw sectors but no special content.  Once I have that I can push data
into the correct sectors as needed.  Its something I am aware of as I've been hacking
CP/M on machines since the mid 70s and that means 8/5.25/3/5 inch drives with maybe
25 or more common formats.  That's so I can salvage apps and data.  In that case the
OS is available so nothing to get worked up about. the opposite case is creating
bootable disks for systems that were missing them by putting the boot tracks
(CCP/BDOS/BIOS) on the media and a few useful applications tools.  I can do that
from one of my home cooked systems as well as it has all the standard sized drives
and locally grown software.  

Once you get into disks based system all of the above is pretty much required.

likely a sip from a firehose.

Allison

Re: MS2000 MicroDos Development System

cmdrcosmac
 


Since the track and sector numbers are different for PC and MicroDOS, how do we use the PC
to format a disk that MicroDOS can use? Is there a utility for Windows (or DOS window in Windows)
that will allow you to set up a custom geometry?
-Chuck

Re: MS2000 MicroDos Development System

ajparent1/kb1gmx
 

My .02$...  
Set up a PC with a floppy of similar type.  Use that to format media.  Use an
old OS DOS works  for that.  If the achine is old enough It will have a useful
serial port.  Since PCs are universally 765 based they can do it.

Why suggest that?   Its been experience that getting a OS and floppy going
on a untested system can be  frustrating and error laden. So starting with
known media (even if blank) can be very helpful.  That being, can ut71
read a sector and write a valid sector back?

At some point a formatter is needed.  Right now you need formatted media
and a older PC running DOS or linux can do that.  

Allison

Re: MS2000 MicroDos Development System

gregory simmons
 

This is somewhat off topic so hopefully I'll be forgiven; feeling nostalgic.  Tom Pittman said that machine language is the ultimate source code (or words to that effect).  I remember disassembling the diskette code for my old TI 99/4 back in 1983... that taught me so much about the details of how diskette drives work.  I think it used a FD1771?  Of course, I had a working system then, and didn't have to troubleshoot hardware or figure out options... I'm sure I couldn't have done that.  

On the other hand, have you ever had the experience where, after disassembling something and understanding it 95%, you run across the actual source code, and think, "Oh, so that's why they did such-and-such!"?

greg AB8IM  

On Friday, December 6, 2019, 06:16:06 PM EST, ajparent1/kb1gmx <kb1gmx@...> wrote:


I found the disk routines easiest having worked with the part extensively.
I know what it expects and what order.  The uPD765 was one of those looks
really strange and was hard to understand until you did.

The 1802 syntax and macros tend to obscure things more than make them clear.
That may be due to most other systems I've used the macros have to stated
outright beforehand so the mental substitution is clear.  No so for that code
as best I can see its all either unseen libraries or shorthand the assembler
knows.  Having the .lst file helped decodde some and make other more
mystifying.   A18 will assemble that or is a there a missing .h or include file?

Allison

Re: MS2000 MicroDos Development System

cellarcat
 

Thanks, Dave. I will definitely give this a try although at the moment I have another digital screwup in that the onboard USB in my MacPro has started to get very erratic. This was my serial connection to the 1802 so right now I am unable to connect at all. I have a pci-e Usb card on the way. Should be here next week. Hopefully that will solve the problem. If not I guess I will have to look at another motherboard upgrade. My third!

On Dec 6, 2019, at 5:58 PM, David Schultz <david.schultz@...> wrote:

I have been working on disassembling the disk format program which could
be handy once you get your system working if you want to format disks.
Uploaded to the MicroDOS folder as FORMAT.asm for the asl assembler.

This program calls the disk I/O routines in UT71 to do most of the work
but a key detail is that data for the CMD routine that sends commands to
the 765 also includes values for the byte count and control registers on
the FDC board. Which means that FORMAT.CM has to be patched in two
places in order to assert motor on.

After formatting a track the program reads the track back to verify it
was written correctly.

If you want to just patch FORMAT.CM this should let you do that:

Address current change to
00F7H 02H 0AH
0146H 01H 09H





--
https://web.archive.org/web/20190214181851/http://home.earthlink.net/~david.schultz/
(Web pages available only at the Wayback Machine because Earthlink
terminated that service.)


Re: MS2000 MicroDos Development System

David Schultz
 

I have been working on disassembling the disk format program which could
be handy once you get your system working if you want to format disks.
Uploaded to the MicroDOS folder as FORMAT.asm for the asl assembler.

This program calls the disk I/O routines in UT71 to do most of the work
but a key detail is that data for the CMD routine that sends commands to
the 765 also includes values for the byte count and control registers on
the FDC board. Which means that FORMAT.CM has to be patched in two
places in order to assert motor on.

After formatting a track the program reads the track back to verify it
was written correctly.

If you want to just patch FORMAT.CM this should let you do that:

Address current change to
00F7H 02H 0AH
0146H 01H 09H





--
https://web.archive.org/web/20190214181851/http://home.earthlink.net/~david.schultz/
(Web pages available only at the Wayback Machine because Earthlink
terminated that service.)

New file uploaded to cosmacelf@groups.io

cosmacelf@groups.io Notification <cosmacelf+notification@...>
 

Hello,

This email message is a notification to let you know that the following files have been uploaded to the Files area of the cosmacelf@groups.io group.

Uploaded By: David Schultz <david.schultz@...>

Description:
FORMAT.CM disassembled, cleaned up, and comments added.

Cheers,
The Groups.io Team