Oh, if that's all it costs, then I agree that the hassle would not be justified. Certainly at my 'hourly rate' (and I imagine that of very many others), to pay up would be the most cost-effective course
Kind Regards, John.
The Essential Guide aka The Technical Manual
- Thread starter sparkiemike
- Start date
Kind Regards, John.
Sponsored Links
I am currently (as I type) doing the 1st amendment update on line via Virtual College/NICEIC. It's about two hours.
Cost me approximately £40 with some voucher discounts. It's ok-ish
Cost me approximately £40 with some voucher discounts. It's ok-ish
I couldn't agree more. I 'resisted' GUIs and Windows for as long as I could, but eventually had to succumb and get Windows 2, fairly soon upgraded to Windows for Workgroups.
My baptism of fire with programming was (in the very early 80's) writing an 'operating system' and word processor in Z80 machine code (none of that sissy Assember stuff
) for a machine I had designed and built. Initially, I only had a total of 8KB of (static) memory to play with (and, of course, no magnetic storage of any sort). Since that 8K had to accommodate program, documents and 'workspace' ('OS'was on EPROM), the size of the word processor had to be limited to about 1.5KB in size. It worked fine, and I used it to run a business for about 10 years, and it actually still works (with a Z80 emulator). It may be somewhat 'less featured' than Word but what can one expect when it is so many orders of magnitude smaller?Kind Regards, John.
That is the point of this thread - but it has been hijacked about ripping software and dos vs windows.
Judging by some of the replies I doubt the link was even clicked by some.Sponsored Links
That is the point of this thread - but it has been hijacked about ripping software and dos vs windows.
I'm afraid that I am one of the culprits in the alleged (and probably factual) hijacking attempt. However, I did click and vote (last night) yes for an offline version. Sincere apologies from a hijacking gang member who wishes to state (in his defence) that it was all in good spirits.
FWIW, I (another member of the hijack team) also voted Yes (three times!! **), as a matter of principle.
** It's actually a poorly set-up poll. One can vote as many times as one likes, simply by returning to the 'poll page'. I thought my second success may have been a fluke, so tried a third time to confirm
Kind Regards, John
My baptism of fire with programming was (in the very early 80's) writing an 'operating system' and word processor in Z80 machine code (none of that sissy Assember stuff
Ah, now if memory serves me right (and it may not) the only difference between writing assembler and machine code on a Z80 was that you had a manual (written) look up table (instruction set) to convert the machine code (1s & 0s in bytes, nibbles etc) into assembler instructions. So you might as well just use assembler. I coded in assembly language and machine code on a 16 bit Texas Instruments 960 (had the 16 data/address bit switches right on the front panel and had the infamous communications register unit (CRU) I/O addressing mode to tangle with) We coded for real time machine control! None of that spreadsheet/word processor relax, have a cup of coffee and do it in your own time stuff for me. We had just a few milliseconds (sometimes microseconds) between success and failure especially when attempting to sync a real time I/O operation between a background and a foreground task. Of course we also lived in a gravel pit in the middle of the road but that's not important right now
Address resolution?
I would certainly have used Assembly Language if I could, since it offered more advantage over direct machine code than your suggesting. In particular, it would have taken all the drruggery out of relative addressing and jumps etc. Whilst I was doing it, I was forever surrounded by scraps of squared paper, and counting the magnitudes of the address offsets and jumps etc.!
HOWEVER, you underestimate the extent to which I was 'at square one' at the time. Z80 Assemblers did exist in 1980, but (1) they were fearfully expensive and (2) one could obviously only use an Assembler if one had a computer (with a recognised OS) on which to run it. At the time, I did not have any functioing computer, only the one I had just built which was awaiting an 'operating system' before it could do anything at all - so I had no choice but to write it directly in machine code. Even once I'd done that and got it working, no commercial Assembler would have been able to run on it. I did eventually write myself a dis-assembler (much easier than an assembler to write) and address-offset calculating programs, again in machine code, and they aided a lot in subsequent machine code software development (e.g. of the 'word processor').
I did subsequently have some attempts at writing directly in machine code for 16-bit processors, but it proved to be far too tedious to be practical.
Kind Regards, John.
I don't think so but maybe wrong. It's been 30+ years. For example the Z80 assembler used HEX addressing and that equates to binary like this:
HEX BINARY
FF = 1111:1111
FE = 1111:1110
AA= 1010:1010
AB = 1010:1011
So addressing should always be able to be done at full resolution (all addresses available)
You could load an address with data something like this:
If the address register contains say the address F1 (1111:0001)
Then you could load that address with the data say 55 (0101:0101)
LD HL, 55 would result in memory address F1 containing the data 55.
However, it may take the odd additional machine cycle in assembler VS direct machine code. How I wish I could remember
I think you have misunderstood BAS and myself. All my machine coding was done in hex, not binary. The 'address resolution' to which BAS and I have referred relates to the calculation of relative address offsets - which requires a physical map of memory, some counting, and then some hex addition or subtraction. An assembler does most of that for one.
Kind Regards, John.
But did the Z80 not have linear addressing up to 64K? (plus I/O addressing)
So a relative jump of say 1000 (decimal to keep it simple) from address 1000 would result in a program counter (if that was the name can't remember) being at absolute 2000?
If that is true then I agree a bit more work without an assembler but not too much. I would have thought the most engaging reason for writing directly in machine code (if an assembler was available) would be for speed reasons (saving machine cycles)
EDIT, aha but you have provided other reasons in a reply while I was wring this so I will read
I think you're missing the nature of the problems. What you say above is true, BUT, if one is writing in machine code, (1) one has to ascertain that the instruction one's writing is at address 1000, (2) then one has to hunt through one's scribbles and records to ascertain what absolute address one wants to jump or refer to, and (3) one then subtracts 1000 from that target address (or vice versa) to get the relative offset (with appropriate adjustments for sign - I forget the convention). It's stage (2) which takes all the time.
With an assembler, one does not have to 'micro-manage' absolute addresses. Indeed, one usually doesn't know anything about absolute addresses, and one certainly does not have to 'manually' allocate (and record on scraps of paper!) storage addresses for each routine and each and every byte one wants to store in memory. Instead, one can use tokens and labels within one's assembler code and can simply specify them as the targets. In other words, one can write an assembler instruction to 'copy John to Gill' or 'jump execution to SubRoutine5', without needing to know the addresses of the instruction one is writing or of the target(s) one is invoking.
An assembler is not an interpreter, or even a compiler. It is just an aid to writing the exact same machine code which one could write directly. The end-product is simply machine code - so unlike interpreted (and compiled in some cases) code, there is no performance consequence of writing machine code using an assembler.
Kind Regards, John.
Now I see, you had no OS to support an assembler! How did you store your programs? Did you have to re-enter it all after power up/bootstrap etc?
I see, but surely you had an OS by the time you wrote a word processor otherwise how would you manage files, store files etc? Did you store them
just in memory only?
In the early days of the TI 960 we wrote purely in machine code (I agree very tedious) but there was no other way. We stored the programs on punched cards later magnetic tape. Then an assembler was presented to us so we wrote most of the code in assembler and minute time critical sections directly in machine code. For debugging on the actual machine (these were production machines - early robotic systems) we simply went directly to a memory address and modified the data at the address. We did that purely in binary though most of the time we were only modifying parameters which was data not instructions.
Much later we replaced the 960s with unix based main frames and wrote in pascal, then Borland Pascal in the 80s. But even then it was not all high level programming. Again, for time critical events we would "link in" a section of code written in assembly language or actually manipulate a direct memory location if it was a simple "tweak"
That is true but the assembler that we used did not always adopt the most efficient methods and I assume the Z80 assembler may have been similar.
For example (and I can't remember the details) bit shifting left/right during additions etc. We would sometimes fine tune time critical events and often save many machine cycles which was critical when trying catch an external event such as a rising/falling edge of a signal from a trigger point etc.
DIYnot Local
Staff member
If you need to find a tradesperson to get your job done, please try our local search below, or if you are doing it yourself you can find suppliers local to you.
Select the supplier or trade you require, enter your location to begin your search.
Are you a trade or supplier? You can create your listing free at DIYnot Local
Sponsored Links
