Last visit was: Sun Apr 21, 2024 7:19 am
It is currently Sun Apr 21, 2024 7:19 am



 [ 102 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next
 rf68000 - 68k similar core 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Discovered the wonderful FSCALE instruction. Of great use to multiply by powers of 10. Works easily for decimal floating point. FSCALE takes only three clock cycles to add to the exponent making it about a hundred times faster than using an FMUL.

Latest Fixes
BCD subtract was not implemented properly. This led to an infinite loop in the float to string conversion.

The decimal float subtractor takes longer to process than addition. So, the addsub primitive is given the worst amount of time to execute. This is about 50 clocks for a subtract, while add takes only about 30 clocks. Since it is hard to tell whether an add or a sub will take place 50 clocks are allotted for either.

_________________
Robert Finch http://www.finitron.ca


Mon Dec 12, 2022 5:09 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Latest Fixes
Clearing a register, CLR did not work. The result bus was not set to zero, so an unknown value would be written to the register. Clear of memory did work. I used MOVEQ everywhere to set a register to zero, so this went unnoticed. The CLR instruction was being used in exponent processing, causing the incorrect exponent to be displayed.

Latest Issues
Trying to get a proper display of a float value. Apparently 256+256 equals 500 according to the current code. Only first digit was correct. It did get 6+6=12 correct though. So, it is not strictly a first digit thing. 2+2=’4.’ Note four is displayed with a decimal point with no following digits. Yet 1+1=2 displays correctly; the decimal point suppression code worked in that case.

256-256 = 0.1e-1534 apparently; I find this hard to understand. There is code in the subtractor to set the result to zero if both operands are the same. So, I do not know how it would be 1 bit off. Maybe something in the rounder.

It looks like FADD, FSUB, and FMUL are working correctly despite display issues. FDIV seems to be out-to-lunch.

I added a small test program to the monitor to take two constants and add, subtract, multiply or divide them.

_________________
Robert Finch http://www.finitron.ca


Tue Dec 13, 2022 4:01 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Milestone
Figured out why only the first leading digit was being displayed and now display of floating-point numbers is much closer to correct. One of the factors in extracting digits needed to be scaled by 10 in each loop iteration and it was not. FADD and FSUB return the correct results and are displaying correctly in scientific notation. FMUL works only for small products less than 256, but I think I have this fixed now. It should be fixed in the latest build. FDIV still seems out-to-lunch.

Discovery
Found a much faster way to do DPD divide. Convert the operands to binary, do the divide in binary, then convert the result operands back into BCD. The BCD to binary and binary to BCD conversions are much faster than a DPD divide which uses repeated subtraction. It can take thousands of clock cycles to do the divide in BCD versus hundreds for the conversions and binary divide.

Latest Mods
Modified the decimal floating-point load and store to make use of the existing long-word load and store states. These states can handle unaligned data, so now floating-point data does not need to be aligned to long-word addresses. Added some more FPU functionality to the core. Not sure how far I want to take it with the rf68k. I just wanted to be able to prove the operation of float-instructions.

_________________
Robert Finch http://www.finitron.ca


Wed Dec 14, 2022 4:26 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Milestone
FDIV working.

Discovered the faster way of doing a DPD divide is not very accurate. It worked for dividing by powers of 10, but not much else. So, I switched back to the “old” way of repeated subtraction and got that to work.

Managed to reuse the MOVEM states to implement FMOVEM at minimal cost.

Blew the LUT budget again. So, I axed another pair of cores. That leaves only a dual-core system if DFP is present.

_________________
Robert Finch http://www.finitron.ca


Thu Dec 15, 2022 5:55 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Latest Issue
Attempting to get a floating-point number crashes the system. The stack is getting corrupted somehow causing a return to address zero, which usually causes a reboot.

Latest Mods
Added floating-point support to TinyBasic. It does not quite work yet :) All numbers are now floats. Some of the code in TinyBasic was removed. For instance, the FMUL instruction is used instead of the multiply routine. Also added local variables for subroutines. The local variables are named L0 to L7, there is only eight of them. TinyBasic has only 26 variables A to Z.

Latest Additions
Added support for the FABS instruction which reuses most of the FNEG instruction code. They are almost the same.

Latest Fixes
The FMOVE instruction was sometimes incorrectly going through the integer-to-float conversion when it was not needed. This led to incorrect values in registers.
Loading and storing of triple precision values was adding to the effective address. This did not work in conjunction with the load and store multiple instructions. The load and store were modified to subtract out the additions at completion.

Direction
More and more code is being added to the 68k core to support floating-point. I am not sure I will keep this up because there is no compiler for it. Modifying an existing compiler to generate the appropriate floating-point code is non-trivial. I would rather invest in a newer a processor.

_________________
Robert Finch http://www.finitron.ca


Fri Dec 16, 2022 4:15 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Latest Fixes
Found a bug in the 96-bit store code used by the FMOVE instruction. It was incrementing the address by too much causing a write to the wrong memory location. In the failing case this was on the stack where the return address was located. Found the bug by inspection after reviewing the code for about the 50th time. Fixing this error did
not fix things.

Did some code clean-up to make the code more reusable by saving and restoring registers in use. The code still seems not to work.

FSCALE was messed up if the source operand was a floating-point register. This was found by inspection. The FSCALE instruction had yet to be used in that manner.

Latest Additions
Added a stack canary check instruction, CCHK, to the instruction set. I added some code to do canary checks to try and debug crash issues then realized a single instruction could replace the code. It uses the same vector as the CHK instruction.

_________________
Robert Finch http://www.finitron.ca


Sat Dec 17, 2022 11:21 am WWW

Joined: Thu Jan 17, 2013 4:38 pm
Posts: 53
Are you amending the 68K instruction set?
How about a version of dbCC that does a long instead of word subtract? (Potential encoding is to steal LSB of offset to flag it - anyone using odd offsets will crash anyway.)


Sat Dec 17, 2022 8:17 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
Are you amending the 68K instruction set?
How about a version of dbCC that does a long instead of word subtract? (Potential encoding is to steal LSB of offset to flag it - anyone using odd offsets will crash anyway.)

It is a good idea. The assembler would need to be modified to support it. I am not sure I want to make that kind of mod to the assembler.

I am not really amending the 68k instruction set. The existing instructions should all work as they do for the 68k. I wanted to be able to use an existing compiler / assembler / linker. What is “amended” is the FPU which is decimal rather than binary. However, I have added a couple of ‘A’ line instructions like CCHK, BIN2BCD and BCD2BIN. I believe these have been added in a non-conflicting way with existing ‘A’ line extensions.

If I were to amend the instruction set, I would give it a different name. DBcc is one of the instructions that could be improved. Multiply and divide are a couple more.

Since adding the canary check instructions the float tests no longer crash. I do not know why.

Added the TICK and CORENO special variables to TinyBasic. Also added support for IRQ routines.

_________________
Robert Finch http://www.finitron.ca


Sun Dec 18, 2022 4:16 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Latest Fixes
The GetFloat() routine was only negating the integer part of the number leading to incorrect values for negative numbers. GetFloat() was not backing up the character pointer in a couple of places leading to issues parsing following text. This showed up in TInyBasic.

_________________
Robert Finch http://www.finitron.ca


Mon Dec 19, 2022 3:56 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Latest Mods
Added strings to TinyBasic. In theory it should be possible to assign a string to a variable, and to concatenate strings. Other string functions are not present yet.

TinyBasic has hiccups yet with floating point. Numbers are being recognized at the lowest level of the expression parser, as can be seen via dumps, but do not seem to be properly passed back up the expression tree.

_________________
Robert Finch http://www.finitron.ca


Tue Dec 20, 2022 4:01 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Latest Fixes
A typo in the FETCH_HEXI states caused it to skip over loading part of the floating-point register. This resulted in the value being close to zero if the register was being loaded from memory. Fixing this, fixed issues in TinyBasic.
A typo in the FMOVE instruction led the memory to register move to always do a register-to-register move. This caused incorrect values to be displayed in TinyBasic.

Milestone:
The LEFT$() function almost works. The function itself appears to work, but for some reason the original variable is having a single character truncated off the end.
Code:
A=”Hello”
Print LEFT$(A,2)
Prints:
He

But it leaves A = “Hell”

To do string processing storage from the string area of memory is allocated and the string copied to allocated storage. My first attempt did not make copies of strings in program text. The issue with that was if a direct statement is issued it is treated as program text and the strings ended up corrupted because there is only a small direct buffer.

I really wanted to get string processing working as it makes it easier to implement a shell with shell variables.

Giving TinyBasic a bit more RAM and making it not-so-tiny could have 1024 variables. Two letter variable names 0-31 for each character for a total of ten bits. TinyBasic would consume 16k for variables then, but this is the 68k with a 32-bit address space.

Variables can have any type. There is no ‘$’ in the naming convention for strings.

FOR / NEXT loops work with floating-point values.

_________________
Robert Finch http://www.finitron.ca


Wed Dec 21, 2022 3:55 am WWW

Joined: Mon Oct 07, 2019 2:41 am
Posts: 593
The 68000 may have had large memory space for the 1980's, but 128KB seemed typical for the time. It seems that most developers
of hardware, felt 64k user space was all you needed. Number crunching, buy a CRAY like APPLE did. Tiny Basic had to stay tiny.
I hope you can find a 68000 OS, that lets you make the most out your machine.


Wed Dec 21, 2022 9:34 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
Tiny Basic had to stay tiny.
I think I may need a new name for TinyBasic. While the version with floats was about the same size as the integer version adding string handling increased the size quite a bit. It is still under 2,700 LOC, so it is not real large. But I am planning on expanding it further too.

Latest Fixes
It has been a week or so since a bug was updated for non-FPU 68k code. A bug was found in the move instruction when the target operand was an address register. Flags were being updated and they are not supposed to be. This showed up as an error in TinyBasic. Deleting lines of text was not working.

Got string concat working, well almost. It is concatenating in the wrong order. Easily fixed by swapping a couple of registers. Both LEFT$ and RIGHT$ seems to be working however MID$ does not. This is strange since both LEFT and RIGHT are implemented using the MID code. LEFT(str,n) is implemented as MID(str,0,n).
Got MID$() working now.

Latest Issues
String garbage collection is not working limiting what can be done with strings.

My simple program to test string concat quits after displaying about 50 lines on the display. B constantly gets one character larger. The 'NEW' and '<CON' are used since the program is being transferred via the serial port.
Code:
NEW
900 B=""
1000 S=RND(26)
1100 A=MID$("abcdefghijklmnopqrstuvwxyz",S,1)
1110 S=RND(26)
1120 C=MID$("ABCDEFGHIJKLMNOPQRSTUVWXYZ",S,1)
1130 S=RND(2)
1140 B=B+MID$(A+C,S,1)
1150 PRINT B
1160 GOTO 1000
<CON


Redirecting output to the serial port so that a program could be saved by TinyBasic had a strange result. The line numbers did not go to the serial port, but the program text did. Turns out that the line numbers were printed using a routine that always displayed to the screen.

_________________
Robert Finch http://www.finitron.ca


Thu Dec 22, 2022 5:16 am WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1783
NIce that Tiny Basic has helped to uncover some CPU misbehaviours...


Thu Dec 22, 2022 7:19 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
NIce that Tiny Basic has helped to uncover some CPU misbehaviours...
Yes. It is nice to have some 68k code that can be easily ported. I think the best way to find bugs is to run a lot of code. I have found several that were not caught by the explicit CPU test program. A bigger BASIC interpreter might be in order. But most interpreters handle floating point code with code, not using the FPU. I should look and see if there is a MS BASIC interpreter for the 68k.

Added the LEN, INT and CHR$ functions to Basic.

_________________
Robert Finch http://www.finitron.ca


Fri Dec 23, 2022 9:53 am WWW
 [ 102 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next

Who is online

Users browsing this forum: CCBot, SemrushBot and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software